~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-04-06 06:59:03 UTC
  • mfrom: (5051.5.1 subunit)
  • Revision ID: pqm@pqm.ubuntu.com-20100406065903-y9dxgwmog1pmw7dz
Use subunit when running tests in PQM.

Show diffs side-by-side

added added

removed removed

Lines of Context:
458
458
Testing locking behaviour
459
459
-------------------------
460
460
 
461
 
In order to test the locking behaviour of commands, it is possible to install
462
 
a hook that is called when a write lock is: acquired, released or broken.
463
 
(Read locks also exist, they cannot be discovered in this way.)
464
 
 
465
 
A hook can be installed by calling bzrlib.lock.Lock.hooks.install_named_hook.
466
 
The three valid hooks are: `lock_acquired`, `lock_released` and `lock_broken`.
467
 
 
468
 
Example::
469
 
 
470
 
    locks_acquired = []
471
 
    locks_released = []
472
 
 
473
 
    lock.Lock.hooks.install_named_hook('lock_acquired',
474
 
        locks_acquired.append, None)
475
 
    lock.Lock.hooks.install_named_hook('lock_released',
476
 
        locks_released.append, None)
477
 
 
478
 
`locks_acquired` will now receive a LockResult instance for all locks acquired
479
 
since the time the hook is installed.
480
 
 
481
 
The last part of the `lock_url` allows you to identify the type of object that is locked.
482
 
 
483
 
- BzrDir: `/branch-lock`
484
 
- Working tree: `/checkout/lock`
485
 
- Branch: `/branch/lock`
486
 
- Repository: `/repository/lock`
487
 
 
488
 
To test if a lock is a write lock on a working tree, one can do the following::
489
 
 
490
 
    self.assertEndsWith(locks_acquired[0].lock_url, "/checkout/lock")
491
 
 
492
 
See bzrlib/tests/commands/test_revert.py for an example of how to use this for
493
 
testing locks.
494
 
 
 
461
You may want to write tests that particular objects are or aren't locked
 
462
during particular operations: see for example `bug 498409`__.  
 
463
 
 
464
 __ https://launchpad.net/bugs/498409
 
465
 
 
466
The `TestCase` base class registers hooks that record lock actions into 
 
467
``._lock_actions`` in this format::
 
468
 
 
469
  [
 
470
    ('acquired', LockResult(file:///tmp/testbzr-J2pcy2.tmp/.bzr/branch-lockc4au55ppz8wdym11z1aq)),
 
471
    ('released', LockResult(file:///tmp/testbzr-J2pcy2.tmp/.bzr/branch-lockc4au55ppz8wdym11z1aq)),
 
472
    ('acquired', LockResult(file:///tmp/testbzr-J2pcy2.tmp/.bzr/repository/lockyxb3rn4sw1oyx1jzkt45)),
 
473
    ('released', LockResult(file:///tmp/testbzr-J2pcy2.tmp/.bzr/repository/lockyxb3rn4sw1oyx1jzkt45)),
 
474
    ('acquired', LockResult(file:///tmp/testbzr-J2pcy2.tmp/.bzr/branch/lockh8c6t28rcjdkgxtndbje)),
 
475
    ('released', LockResult(file:///tmp/testbzr-J2pcy2.tmp/.bzr/branch/lockh8c6t28rcjdkgxtndbje)),
 
476
    ...
 
477
 
 
478
Alternatively you can register your own hooks to make custom assertions:
 
479
see `TestCase._check_locks` for an example.
495
480
 
496
481
Skipping tests
497
482
--------------
772
757
 
773
758
TestCase
774
759
    A base TestCase that extends the Python standard library's
775
 
    TestCase in several ways.  TestCase is build on
776
 
    ``testtools.TestCase``, which gives it support for more assertion
777
 
    methods (e.g.  ``assertContainsRe``), ``addCleanup``, and other
778
 
    features (see its API docs for details).  It also has a ``setUp`` that
779
 
    makes sure that global state like registered hooks and loggers won't
780
 
    interfere with your test.  All tests should use this base class
781
 
    (whether directly or via a subclass).  Note that we are trying not to
782
 
    add more assertions at this point, and instead to build up a library
783
 
    of ``bzrlib.tests.matchers``.
 
760
    TestCase in several ways.  It adds more assertion methods (e.g.
 
761
    ``assertContainsRe``), ``addCleanup``, and other features (see its API
 
762
    docs for details).  It also has a ``setUp`` that makes sure that
 
763
    global state like registered hooks and loggers won't interfere with
 
764
    your test.  All tests should use this base class (whether directly or
 
765
    via a subclass).
784
766
 
785
767
TestCaseWithMemoryTransport
786
768
    Extends TestCase and adds methods like ``get_transport``,