← Back to branch summary

~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-02-11 04:02:41 UTC
  • mfrom: (5017.2.2 tariff)
  • Revision ID: pqm@pqm.ubuntu.com-20100211040241-w6n021dz0uus341n
(mbp) add import-tariff tests

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/testing.txt
144
144
-------------
145
145
 
146
146
Bazaar can optionally produce output in the machine-readable subunit_
147
 
format, so that test output can be post-processed by various tools. To
148
 
generate a subunit test stream::
149
 
 
150
 
 $ ./bzr selftest --subunit
151
 
 
152
 
Processing such a stream can be done using a variety of tools including:
153
 
 
154
 
* The builtin ``subunit2pyunit``, ``subunit-filter``, ``subunit-ls``,
155
 
  ``subunit2junitxml`` from the subunit project.
156
 
 
157
 
* tribunal_, a GUI for showing test results.
158
 
 
159
 
* testrepository_, a tool for gathering and managing test runs.
 
147
format, so that test output can be post-processed by various tools.
160
148
 
161
149
.. _subunit: https://launchpad.net/subunit/
162
 
.. _tribunal: https://launchpad.net/tribunal/
163
 
 
164
 
 
165
 
Using testrepository
166
 
--------------------
167
 
 
168
 
Bazaar ships with a config file for testrepository_. This can be very
169
 
useful for keeping track of failing tests and doing general workflow
170
 
support. To run tests using testrepository::
171
 
 
172
 
  $ testr run
173
 
 
174
 
To run only failing tests::
175
 
 
176
 
  $ testr run --failing
177
 
 
178
 
To run only some tests, without plugins::
179
 
 
180
 
  $ test run test_selftest -- --no-plugins
181
 
 
182
 
See the testrepository documentation for more details.
183
 
 
184
 
.. _testrepository: https://launchpad.net/testrepository
 
150
 
 
151
 
185
152
 
186
153
Writing Tests
187
154
=============
455
422
  unless there is a good reason
456
423
 
457
424
 
458
 
Testing locking behaviour
459
 
-------------------------
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
 
 
495
 
 
496
425
Skipping tests
497
426
--------------
498
427
 
614
543
 - UnicodeFilenameFeature
615
544
 - FTPServerFeature
616
545
 - CaseInsensitiveFilesystemFeature.
617
 
 - chown_feature: The test can rely on OS being POSIX and python
618
 
   supporting os.chown.
619
 
 - posix_permissions_feature: The test can use POSIX-style
620
 
   user/group/other permission bits.
621
546
 
622
547
 
623
548
Defining a new feature that tests can require