6
6
The Importance of Testing
7
7
=========================
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.
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
187
Babune continuous integration
188
-----------------------------
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.)
395
352
The actual use of ScriptRunner within a TestCase looks something like
398
from bzrlib.tests import script
400
def test_unshelve_keep(self):
402
script.run_script(self, '''
404
$ bzr shelve --all -m Foo
407
$ bzr unshelve --keep
355
def test_unshelve_keep(self):
358
sr.run_script(self, '''
360
$ bzr shelve --all -m Foo
363
$ bzr unshelve --keep
415
371
Import tariff tests
431
387
dependencies and only needed for particular cases. If they're loaded in
432
388
other cases then bzr may break for people who don't have those modules.
434
`test_import_tariff` allows us to check that removal of imports doesn't
390
`test_import_tarrif` allows us to check that removal of imports doesn't
437
393
This is done by running the command in a subprocess with
466
422
unless there is a good reason
469
Testing locking behaviour
470
-------------------------
472
In order to test the locking behaviour of commands, it is possible to install
473
a hook that is called when a write lock is: acquired, released or broken.
474
(Read locks also exist, they cannot be discovered in this way.)
476
A hook can be installed by calling bzrlib.lock.Lock.hooks.install_named_hook.
477
The three valid hooks are: `lock_acquired`, `lock_released` and `lock_broken`.
484
lock.Lock.hooks.install_named_hook('lock_acquired',
485
locks_acquired.append, None)
486
lock.Lock.hooks.install_named_hook('lock_released',
487
locks_released.append, None)
489
`locks_acquired` will now receive a LockResult instance for all locks acquired
490
since the time the hook is installed.
492
The last part of the `lock_url` allows you to identify the type of object that is locked.
494
- BzrDir: `/branch-lock`
495
- Working tree: `/checkout/lock`
496
- Branch: `/branch/lock`
497
- Repository: `/repository/lock`
499
To test if a lock is a write lock on a working tree, one can do the following::
501
self.assertEndsWith(locks_acquired[0].lock_url, "/checkout/lock")
503
See bzrlib/tests/commands/test_revert.py for an example of how to use this for
625
543
- UnicodeFilenameFeature
626
544
- FTPServerFeature
627
545
- CaseInsensitiveFilesystemFeature.
628
- chown_feature: The test can rely on OS being POSIX and python
630
- posix_permissions_feature: The test can use POSIX-style
631
user/group/other permission bits.
634
548
Defining a new feature that tests can require
785
699
A base TestCase that extends the Python standard library's
786
TestCase in several ways. TestCase is build on
787
``testtools.TestCase``, which gives it support for more assertion
788
methods (e.g. ``assertContainsRe``), ``addCleanup``, and other
789
features (see its API docs for details). It also has a ``setUp`` that
790
makes sure that global state like registered hooks and loggers won't
791
interfere with your test. All tests should use this base class
792
(whether directly or via a subclass). Note that we are trying not to
793
add more assertions at this point, and instead to build up a library
794
of ``bzrlib.tests.matchers``.
700
TestCase in several ways. It adds more assertion methods (e.g.
701
``assertContainsRe``), ``addCleanup``, and other features (see its API
702
docs for details). It also has a ``setUp`` that makes sure that
703
global state like registered hooks and loggers won't interfere with
704
your test. All tests should use this base class (whether directly or
796
707
TestCaseWithMemoryTransport
797
708
Extends TestCase and adds methods like ``get_transport``,
added
removed
doc/developers/testing.txt
