/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

  • Committer: Neil Santos
  • Date: 2010-03-04 02:43:41 UTC
  • mto: (5080.1.1 integration)
  • mto: This revision was merged to the branch mainline in revision 5081.
  • Revision ID: neil_santos@users.sourceforge.net-20100304024341-ra7njxj4lzjb46rl
Removed separate lstat() and reverted LocalTransport and SFTPTransport's stat() methods to using lstat() internally.
Reworked how SFTPTransport's symlink() handles success and signals failure.
Removed lstat() declaration on the Transport base class.

Show diffs side-by-side

added added

removed removed

Lines of Context:
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