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::
150
$ ./bzr selftest --subunit
152
Processing such a stream can be done using a variety of tools including:
154
* The builtin ``subunit2pyunit``, ``subunit-filter``, ``subunit-ls``,
155
``subunit2junitxml`` from the subunit project.
157
* tribunal_, a GUI for showing test results.
159
* testrepository_, a tool for gathering and managing test runs.
147
format, so that test output can be post-processed by various tools.
161
149
.. _subunit: https://launchpad.net/subunit/
162
.. _tribunal: https://launchpad.net/tribunal/
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::
174
To run only failing tests::
176
$ testr run --failing
178
To run only some tests, without plugins::
180
$ test run test_selftest -- --no-plugins
182
See the testrepository documentation for more details.
184
.. _testrepository: https://launchpad.net/testrepository
407
`bzrlib.tests.test_import_tariff` has some tests that measure how many
408
Python modules are loaded to run some representative commands.
410
We want to avoid loading code unnecessarily, for reasons including:
412
* Python modules are interpreted when they're loaded, either to define
413
classes or modules or perhaps to initialize some structures.
415
* With a cold cache we may incur blocking real disk IO for each module.
417
* Some modules depend on many others.
419
* Some optional modules such as `testtools` are meant to be soft
420
dependencies and only needed for particular cases. If they're loaded in
421
other cases then bzr may break for people who don't have those modules.
423
`test_import_tarrif` allows us to check that removal of imports doesn't
426
This is done by running the command in a subprocess with
427
``--profile-imports``. Starting a whole Python interpreter is pretty
428
slow, so we don't want exhaustive testing here, but just enough to guard
429
against distinct fixed problems.
431
Assertions about precisely what is loaded tend to be brittle so we instead
432
make assertions that particular things aren't loaded.
434
Unless selftest is run with ``--no-plugins``, modules will be loaded in
435
the usual way and checks made on what they cause to be loaded. This is
436
probably worth checking into, because many bzr users have at least some
437
plugins installed (and they're included in binary installers).
439
In theory, plugins might have a good reason to load almost anything:
440
someone might write a plugin that opens a network connection or pops up a
441
gui window every time you run 'bzr status'. However, it's more likely
442
that the code to do these things is just being loaded accidentally. We
443
might eventually need to have a way to make exceptions for particular
446
Some things to check:
448
* non-GUI commands shouldn't load GUI libraries
450
* operations on bzr native formats sholudn't load foreign branch libraries
452
* network code shouldn't be loaded for purely local operations
454
* particularly expensive Python built-in modules shouldn't be loaded
455
unless there is a good reason
458
Testing locking behaviour
459
-------------------------
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.)
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`.
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)
478
`locks_acquired` will now receive a LockResult instance for all locks acquired
479
since the time the hook is installed.
481
The last part of the `lock_url` allows you to identify the type of object that is locked.
483
- BzrDir: `/branch-lock`
484
- Working tree: `/checkout/lock`
485
- Branch: `/branch/lock`
486
- Repository: `/repository/lock`
488
To test if a lock is a write lock on a working tree, one can do the following::
490
self.assertEndsWith(locks_acquired[0].lock_url, "/checkout/lock")
492
See bzrlib/tests/commands/test_revert.py for an example of how to use this for
added
removed
doc/developers/testing.txt
