/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/developers/testing.txt

  • Committer: Martin Pool
  • Date: 2010-09-14 10:17:30 UTC
  • mto: (5452.4.1 jam-integration)
  • mto: This revision was merged to the branch mainline in revision 5476.
  • Revision ID: mbp@sourcefrog.net-20100914101730-c3bfj0k2y68mxz9z
Update test_resolve to pass --quiet or ignore command output it doesn't care about

Show diffs side-by-side

added added

removed removed

Lines of Context:
6
6
The Importance of Testing
7
7
=========================
8
8
 
9
 
Reliability is a critical success factor for any Version Control System.
 
9
Reliability is a critical success factor for any version control system.
10
10
We want Bazaar to be highly reliable across multiple platforms while
11
11
evolving over time to meet the needs of its community.
12
12
 
183
183
 
184
184
.. _testrepository: https://launchpad.net/testrepository
185
185
 
 
186
 
 
187
Babune continuous integration
 
188
-----------------------------
 
189
 
 
190
We have a Hudson continuous-integration system that automatically runs 
 
191
tests across various platforms.  In the future we plan to add more 
 
192
combinations including testing plugins.  See 
 
193
<http://babune.ladeuil.net:24842/>.  (Babune = Bazaar Buildbot Network.)
 
194
 
 
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
 
186
231
Writing Tests
187
232
=============
188
233
 
343
388
If you want the command to succeed for any output, just use::
344
389
 
345
390
  $ bzr add file
 
391
  ...
 
392
  2>...
 
393
 
 
394
or use the ``--quiet`` option::
 
395
 
 
396
  $ bzr add -q file
346
397
 
347
398
The following will stop with an error::
348
399
 
385
436
The actual use of ScriptRunner within a TestCase looks something like
386
437
this::
387
438
 
388
 
        def test_unshelve_keep(self):
389
 
                # some setup here
390
 
                sr = ScriptRunner()
391
 
                sr.run_script(self, '''
392
 
        $ bzr add file
393
 
        $ bzr shelve --all -m Foo
394
 
        $ bzr shelve --list
395
 
        1: Foo
396
 
        $ bzr unshelve --keep
397
 
        $ bzr shelve --list
398
 
        1: Foo
399
 
        $ cat file
400
 
        contents of file
401
 
        ''')
402
 
 
 
439
    from bzrlib.tests import script
 
440
 
 
441
    def test_unshelve_keep(self):
 
442
        # some setup here
 
443
        script.run_script(self, '''
 
444
            $ bzr add file
 
445
            $ bzr shelve --all -m Foo
 
446
            $ bzr shelve --list
 
447
            1: Foo
 
448
            $ bzr unshelve --keep
 
449
            $ bzr shelve --list
 
450
            1: Foo
 
451
            $ cat file
 
452
            contents of file
 
453
            ''')
 
454
 
 
455
You can also test commands that read user interaction::
 
456
 
 
457
    def test_confirm_action(self):
 
458
        """You can write tests that demonstrate user confirmation"""
 
459
        commands.builtin_command_registry.register(cmd_test_confirm)
 
460
        self.addCleanup(commands.builtin_command_registry.remove, 'test-confirm')
 
461
        self.run_script("""
 
462
            $ bzr test-confirm
 
463
            2>Really do it? [y/n]: 
 
464
            <yes
 
465
            yes
 
466
            """)
403
467
 
404
468
Import tariff tests
405
469
-------------------
420
484
  dependencies and only needed for particular cases.  If they're loaded in
421
485
  other cases then bzr may break for people who don't have those modules.
422
486
  
423
 
`test_import_tarrif` allows us to check that removal of imports doesn't
 
487
`test_import_tariff` allows us to check that removal of imports doesn't
424
488
regress.
425
489
 
426
490
This is done by running the command in a subprocess with
772
836
 
773
837
TestCase
774
838
    A base TestCase that extends the Python standard library's
775
 
    TestCase in several ways.  It adds more assertion methods (e.g.
776
 
    ``assertContainsRe``), ``addCleanup``, and other features (see its API
777
 
    docs for details).  It also has a ``setUp`` that makes sure that
778
 
    global state like registered hooks and loggers won't interfere with
779
 
    your test.  All tests should use this base class (whether directly or
780
 
    via a subclass).
 
839
    TestCase in several ways.  TestCase is build on
 
840
    ``testtools.TestCase``, which gives it support for more assertion
 
841
    methods (e.g.  ``assertContainsRe``), ``addCleanup``, and other
 
842
    features (see its API docs for details).  It also has a ``setUp`` that
 
843
    makes sure that global state like registered hooks and loggers won't
 
844
    interfere with your test.  All tests should use this base class
 
845
    (whether directly or via a subclass).  Note that we are trying not to
 
846
    add more assertions at this point, and instead to build up a library
 
847
    of ``bzrlib.tests.matchers``.
781
848
 
782
849
TestCaseWithMemoryTransport
783
850
    Extends TestCase and adds methods like ``get_transport``,
856
923
Please see bzrlib.treebuilder for more details.
857
924
 
858
925
 
 
926
Temporarily changing state
 
927
~~~~~~~~~~~~~~~~~~~~~~~~~~
 
928
 
 
929
If your test needs to temporarily mutate some global state, and you need
 
930
it restored at the end, you can say for example::
 
931
 
 
932
    self.overrideAttr(osutils, '_cached_user_encoding', 'latin-1')
 
933
 
 
934
Cleaning up
 
935
~~~~~~~~~~~
 
936
 
 
937
Our base ``TestCase`` class provides an ``addCleanup`` method, which
 
938
should be used instead of ``tearDown``.  All the cleanups are run when the
 
939
test finishes, regardless of whether it passes or fails.  If one cleanup
 
940
fails, later cleanups are still run.
 
941
 
 
942
(The same facility is available outside of tests through
 
943
``bzrlib.cleanup``.)
 
944
 
 
945
 
 
946
Manual testing
 
947
==============
 
948
 
 
949
Generally we prefer automated testing but sometimes a manual test is the
 
950
right thing, especially for performance tests that want to measure elapsed
 
951
time rather than effort.
 
952
 
 
953
Simulating slow networks
 
954
------------------------
 
955
 
 
956
To get realistically slow network performance for manually measuring
 
957
performance, we can simulate 500ms latency (thus 1000ms round trips)::
 
958
 
 
959
  $ sudo tc qdisc add dev lo root netem delay 500ms
 
960
 
 
961
Normal system behaviour is restored with ::
 
962
 
 
963
  $ sudo tc qdisc del dev lo root
 
964
 
 
965
A more precise version that only filters traffic to port 4155 is::
 
966
 
 
967
    tc qdisc add dev lo root handle 1: prio
 
968
    tc qdisc add dev lo parent 1:3 handle 30: netem delay 500ms 
 
969
    tc qdisc add dev lo parent 30:1 handle 40: prio
 
970
    tc filter add dev lo protocol ip parent 1:0 prio 3 u32 match ip dport 4155 0xffff flowid 1:3 handle 800::800
 
971
    tc filter add dev lo protocol ip parent 1:0 prio 3 u32 match ip sport 4155 0xffff flowid 1:3 handle 800::801
 
972
 
 
973
and to remove this::
 
974
 
 
975
    tc filter del dev lo protocol ip parent 1: pref 3 u32
 
976
    tc qdisc del dev lo root handle 1:
 
977
 
 
978
You can use similar code to add additional delay to a real network
 
979
interface, perhaps only when talking to a particular server or pointing at
 
980
a VM.  For more information see <http://lartc.org/>.
 
981
 
 
982
 
859
983
.. |--| unicode:: U+2014
860
984
 
861
985
..
862
 
   vim: ft=rst tw=74 ai
 
986
   vim: ft=rst tw=74 ai et sw=4