At file:///home/pqm/archives/thelove/bzr/%2Btrunk/ ------------------------------------------------------------ revno: 5346 [merge] revision-id: p...@pqm.ubuntu.com-20100715110657-zb7pmrur0azigjs5 parent: p...@pqm.ubuntu.com-20100713224310-irt5swwo7ajwg7e5 parent: m...@canonical.com-20100715094716-sljdg6go0d12xi79 committer: Canonical.com Patch Queue Manager <p...@pqm.ubuntu.com> branch nick: +trunk timestamp: Thu 2010-07-15 12:06:57 +0100 message: (mbp) document some tricks about testing bzr (tmpfs, tc qdisc, parallel) (Martin Pool) modified: doc/developers/testing.txt testing.txt-20080812140359-i70zzh6v2z7grqex-1 === modified file 'doc/developers/testing.txt' --- a/doc/developers/testing.txt 2010-06-24 07:11:55 +0000 +++ b/doc/developers/testing.txt 2010-07-15 09:47:16 +0000 @@ -193,6 +193,41 @@ <http://babune.ladeuil.net:24842/>. (Babune = Bazaar Buildbot Network.) +Running tests in parallel +------------------------- + +Bazaar can use subunit to spawn multiple test processes. There is +slightly more chance you will hit ordering or timing-dependent bugs but +it's much faster:: + + $ ./bzr selftest --parallel=fork + +Note that you will need the Subunit library +<https://launchpad.net/subunit/> to use this, which is in +``python-subunit`` on Ubuntu. + + +Running tests from a ramdisk +---------------------------- + +The tests create and delete a lot of temporary files. In some cases you +can make the test suite run much faster by running it on a ramdisk. For +example:: + + $ sudo mkdir /ram + $ sudo mount -t tmpfs none /ram + $ TMPDIR=/ram ./bzr selftest ... + +You could also change ``/tmp`` in ``/etc/fstab`` to have type ``tmpfs``, +if you don't mind possibly losing other files in there when the machine +restarts. Add this line (if there is none for ``/tmp`` already):: + + none /tmp tmpfs defaults 0 0 + +With a 6-core machine and ``--parallel=fork`` using a tmpfs doubles the +test execution speed. + + Writing Tests ============= @@ -889,6 +924,44 @@ (The same facility is available outside of tests through ``bzrlib.cleanup``.) + +Manual testing +============== + +Generally we prefer automated testing but sometimes a manual test is the +right thing, especially for performance tests that want to measure elapsed +time rather than effort. + +Simulating slow networks +------------------------ + +To get realistically slow network performance for manually measuring +performance, we can simulate 500ms latency (thus 1000ms round trips):: + + $ sudo tc qdisc add dev lo root netem delay 500ms + +Normal system behaviour is restored with :: + + $ sudo tc qdisc del dev lo root + +A more precise version that only filters traffic to port 4155 is:: + + tc qdisc add dev lo root handle 1: prio + tc qdisc add dev lo parent 1:3 handle 30: netem delay 500ms + tc qdisc add dev lo parent 30:1 handle 40: prio + tc filter add dev lo protocol ip parent 1:0 prio 3 u32 match ip dport 4155 0xffff flowid 1:3 handle 800::800 + tc filter add dev lo protocol ip parent 1:0 prio 3 u32 match ip sport 4155 0xffff flowid 1:3 handle 800::801 + +and to remove this:: + + tc filter del dev lo protocol ip parent 1: pref 3 u32 + tc qdisc del dev lo root handle 1: + +You can use similar code to add additional delay to a real network +interface, perhaps only when talking to a particular server or pointing at +a VM. For more information see <http://lartc.org/>. + + .. |--| unicode:: U+2014 ..
-- bazaar-commits mailing list bazaar-commits@lists.canonical.com https://lists.ubuntu.com/mailman/listinfo/bazaar-commits
