/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

Add bzrlib.pyutils, which has get_named_object, a wrapper around __import__.

This is used to replace various ad hoc implementations of the same logic,
notably the version used in registry's _LazyObjectGetter which had a bug when
getting a module without also getting a member.  And of course, this new
function has unit tests, unlike the replaced code.

This also adds a KnownHooksRegistry subclass to provide a more natural home for
some other logic.

I'm not thrilled about the name of the new module or the new functions, but it's
hard to think of good names for such generic functionality.

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
 
385
430
The actual use of ScriptRunner within a TestCase looks something like
386
431
this::
387
432
 
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
 
 
 
433
    from bzrlib.tests import script
 
434
 
 
435
    def test_unshelve_keep(self):
 
436
        # some setup here
 
437
        script.run_script(self, '''
 
438
            $ bzr add file
 
439
            $ bzr shelve --all -m Foo
 
440
            $ bzr shelve --list
 
441
            1: Foo
 
442
            $ bzr unshelve --keep
 
443
            $ bzr shelve --list
 
444
            1: Foo
 
445
            $ cat file
 
446
            contents of file
 
447
            ''')
 
448
 
 
449
You can also test commands that read user interaction::
 
450
 
 
451
    def test_confirm_action(self):
 
452
        """You can write tests that demonstrate user confirmation"""
 
453
        commands.builtin_command_registry.register(cmd_test_confirm)
 
454
        self.addCleanup(commands.builtin_command_registry.remove, 'test-confirm')
 
455
        self.run_script("""
 
456
            $ bzr test-confirm
 
457
            2>Really do it? [y/n]: 
 
458
            <yes
 
459
            yes
 
460
            """)
403
461
 
404
462
Import tariff tests
405
463
-------------------
420
478
  dependencies and only needed for particular cases.  If they're loaded in
421
479
  other cases then bzr may break for people who don't have those modules.
422
480
  
423
 
`test_import_tarrif` allows us to check that removal of imports doesn't
 
481
`test_import_tariff` allows us to check that removal of imports doesn't
424
482
regress.
425
483
 
426
484
This is done by running the command in a subprocess with
772
830
 
773
831
TestCase
774
832
    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).
 
833
    TestCase in several ways.  TestCase is build on
 
834
    ``testtools.TestCase``, which gives it support for more assertion
 
835
    methods (e.g.  ``assertContainsRe``), ``addCleanup``, and other
 
836
    features (see its API docs for details).  It also has a ``setUp`` that
 
837
    makes sure that global state like registered hooks and loggers won't
 
838
    interfere with your test.  All tests should use this base class
 
839
    (whether directly or via a subclass).  Note that we are trying not to
 
840
    add more assertions at this point, and instead to build up a library
 
841
    of ``bzrlib.tests.matchers``.
781
842
 
782
843
TestCaseWithMemoryTransport
783
844
    Extends TestCase and adds methods like ``get_transport``,
856
917
Please see bzrlib.treebuilder for more details.
857
918
 
858
919
 
 
920
Temporarily changing state
 
921
~~~~~~~~~~~~~~~~~~~~~~~~~~
 
922
 
 
923
If your test needs to temporarily mutate some global state, and you need
 
924
it restored at the end, you can say for example::
 
925
 
 
926
    self.overrideAttr(osutils, '_cached_user_encoding', 'latin-1')
 
927
 
 
928
Cleaning up
 
929
~~~~~~~~~~~
 
930
 
 
931
Our base ``TestCase`` class provides an ``addCleanup`` method, which
 
932
should be used instead of ``tearDown``.  All the cleanups are run when the
 
933
test finishes, regardless of whether it passes or fails.  If one cleanup
 
934
fails, later cleanups are still run.
 
935
 
 
936
(The same facility is available outside of tests through
 
937
``bzrlib.cleanup``.)
 
938
 
 
939
 
 
940
Manual testing
 
941
==============
 
942
 
 
943
Generally we prefer automated testing but sometimes a manual test is the
 
944
right thing, especially for performance tests that want to measure elapsed
 
945
time rather than effort.
 
946
 
 
947
Simulating slow networks
 
948
------------------------
 
949
 
 
950
To get realistically slow network performance for manually measuring
 
951
performance, we can simulate 500ms latency (thus 1000ms round trips)::
 
952
 
 
953
  $ sudo tc qdisc add dev lo root netem delay 500ms
 
954
 
 
955
Normal system behaviour is restored with ::
 
956
 
 
957
  $ sudo tc qdisc del dev lo root
 
958
 
 
959
A more precise version that only filters traffic to port 4155 is::
 
960
 
 
961
    tc qdisc add dev lo root handle 1: prio
 
962
    tc qdisc add dev lo parent 1:3 handle 30: netem delay 500ms 
 
963
    tc qdisc add dev lo parent 30:1 handle 40: prio
 
964
    tc filter add dev lo protocol ip parent 1:0 prio 3 u32 match ip dport 4155 0xffff flowid 1:3 handle 800::800
 
965
    tc filter add dev lo protocol ip parent 1:0 prio 3 u32 match ip sport 4155 0xffff flowid 1:3 handle 800::801
 
966
 
 
967
and to remove this::
 
968
 
 
969
    tc filter del dev lo protocol ip parent 1: pref 3 u32
 
970
    tc qdisc del dev lo root handle 1:
 
971
 
 
972
You can use similar code to add additional delay to a real network
 
973
interface, perhaps only when talking to a particular server or pointing at
 
974
a VM.  For more information see <http://lartc.org/>.
 
975
 
 
976
 
859
977
.. |--| unicode:: U+2014
860
978
 
861
979
..
862
 
   vim: ft=rst tw=74 ai
 
980
   vim: ft=rst tw=74 ai et sw=4