diff --git a/README-testing b/README-testing
index f43482d..0d70c85 100644
--- a/README-testing
+++ b/README-testing
@@ -1,100 +1,104 @@
 There's a booth-test RPM available that contains two types of tests.
 
 It installs the necessary files into `/usr/share/booth/tests`.
 
 
 === Simple tests (commandline, config file)
 
 
 Run (as non-root)
 
     # python test/runtests.py
 
 to run the tests written in python.
 
 
 
 
 === Unit tests
 
 These use gdb and pexpect to set boothd state to some configured value,
 injecting some input and looking at the output.
 
     # python script/unit-test.py src/boothd unit-tests/
 
+Or, if using the 'booth-test' RPM,
+
+    # python unit-test.py src/boothd unit-tests/
+
 This must (currently?) be run as a non-root user; another optional argument is
 the test to start from, eg. '003'.
 
 
 Basically, boothd is started with the config file `unit-tests/booth.conf`, and
 gdb gets attached to it.
 
 Then, some ticket state is set, incoming messages are delivered, and outgoing
 messages and the state is compared to expected values.
 
 `unit-tests/_defaults.txt` has default values for the initial state and
 message data.
 
 
 Each test file consists of headers and key/value pairs:
 
 --------------------
 ticket:
 	state 		ST_STABLE
 
 message0: 		# optional comment for the log file
         header.cmd      OP_ACCEPTING
         ticket.id       "asdga"
 
 outgoing0:
 	header.cmd 	OP_PREPARING
 	last_ack_ballot 42
 
 finally:
 	new_ballot 	1234
 --------------------
 
 
 A few details to the the above example:
 
 * Ticket states in RAM (`ticket`, `finally`) are written in host-endianness.
 
 * Message data (`messageN`, `outgoingN`) are automatically converted via `htonl` resp. `ntohl`. They are delivered/checked in the order defined by the integer `N` component.
 
 * Strings are done via `strcpy()`
 
 * `ticket` and `messageN` are assignment chunks
 
 * `finally` and `outgoingN` are compare chunks
 
 * In `outgoingN` you can check _both_ message data (keys with a `.` in them) and ticket state
 
 * Symbolic names are useable, GDB translates them for us
 
 * The test scripts in `unit-tests/` need to be named with 3 digits, an underscore, some text, and `.txt`
 
 * The "fake" `crm_ticket` script gets the current test via `UNIT_TEST`; test scripts can pass additional information via `UNIT_TEST_AUX`.
 
 
 
 ==== Tips and Hints
 
 There's another special header: `gdb__N__`. These lines are sent to GDB after
 injecting a message, but before waiting for an outgoing line. Values that
 contain `§` are sent as multiple lines to GDB.
 
 This means that a stanza like
 
 --------------------
 gdb0:
         watch booth_conf->ticket[0].owner § commands § bt § c § end
 --------------------
 
 will cause a watchpoint to be set, and when it is triggered a backtrace (`bt`)
 is written to the log file.
 
 This makes it easy to ask for additional data or check for a call-chain when
 hitting bugs that can be reproduced via such a unit-test.
 
 
 # vim: set ft=asciidoc :