~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/testing.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2010-07-15 11:06:57 UTC
  • mfrom: (5335.3.5 doc-testing)
  • Revision ID: pqm@pqm.ubuntu.com-20100715110657-zb7pmrur0azigjs5
(mbp) document some tricks about testing bzr (tmpfs, tc qdisc,
 parallel) (Martin Pool)

Show diffs side-by-side

added added

removed removed

Lines of Context:
193
193
<http://babune.ladeuil.net:24842/>.  (Babune = Bazaar Buildbot Network.)
194
194
 
195
195
 
 
196
Running tests in parallel
 
197
-------------------------
 
198
 
 
199
Bazaar can use subunit to spawn multiple test processes.  There is
 
200
slightly more chance you will hit ordering or timing-dependent bugs but
 
201
it's much faster::
 
202
 
 
203
  $ ./bzr selftest --parallel=fork
 
204
 
 
205
Note that you will need the Subunit library
 
206
<https://launchpad.net/subunit/> to use this, which is in
 
207
``python-subunit`` on Ubuntu.
 
208
 
 
209
 
 
210
Running tests from a ramdisk
 
211
----------------------------
 
212
 
 
213
The tests create and delete a lot of temporary files.  In some cases you
 
214
can make the test suite run much faster by running it on a ramdisk.  For
 
215
example::
 
216
 
 
217
  $ sudo mkdir /ram
 
218
  $ sudo mount -t tmpfs none /ram
 
219
  $ TMPDIR=/ram ./bzr selftest ...
 
220
 
 
221
You could also change ``/tmp`` in ``/etc/fstab`` to have type ``tmpfs``,
 
222
if you don't mind possibly losing other files in there when the machine
 
223
restarts.  Add this line (if there is none for ``/tmp`` already)::
 
224
 
 
225
  none           /tmp            tmpfs  defaults        0       0
 
226
 
 
227
With a 6-core machine and ``--parallel=fork`` using a tmpfs doubles the
 
228
test execution speed.
 
229
 
 
230
 
196
231
Writing Tests
197
232
=============
198
233
 
889
924
(The same facility is available outside of tests through
890
925
``bzrlib.cleanup``.)
891
926
 
 
927
 
 
928
Manual testing
 
929
==============
 
930
 
 
931
Generally we prefer automated testing but sometimes a manual test is the
 
932
right thing, especially for performance tests that want to measure elapsed
 
933
time rather than effort.
 
934
 
 
935
Simulating slow networks
 
936
------------------------
 
937
 
 
938
To get realistically slow network performance for manually measuring
 
939
performance, we can simulate 500ms latency (thus 1000ms round trips)::
 
940
 
 
941
  $ sudo tc qdisc add dev lo root netem delay 500ms
 
942
 
 
943
Normal system behaviour is restored with ::
 
944
 
 
945
  $ sudo tc qdisc del dev lo root
 
946
 
 
947
A more precise version that only filters traffic to port 4155 is::
 
948
 
 
949
    tc qdisc add dev lo root handle 1: prio
 
950
    tc qdisc add dev lo parent 1:3 handle 30: netem delay 500ms 
 
951
    tc qdisc add dev lo parent 30:1 handle 40: prio
 
952
    tc filter add dev lo protocol ip parent 1:0 prio 3 u32 match ip dport 4155 0xffff flowid 1:3 handle 800::800
 
953
    tc filter add dev lo protocol ip parent 1:0 prio 3 u32 match ip sport 4155 0xffff flowid 1:3 handle 800::801
 
954
 
 
955
and to remove this::
 
956
 
 
957
    tc filter del dev lo protocol ip parent 1: pref 3 u32
 
958
    tc qdisc del dev lo root handle 1:
 
959
 
 
960
You can use similar code to add additional delay to a real network
 
961
interface, perhaps only when talking to a particular server or pointing at
 
962
a VM.  For more information see <http://lartc.org/>.
 
963
 
 
964
 
892
965
.. |--| unicode:: U+2014
893
966
 
894
967
..