← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/testing.txt

  • Committer: Andrew Bennetts
  • Date: 2010-01-15 03:58:20 UTC
  • mfrom: (4963 +trunk)
  • mto: (4973.1.1 integration)
  • mto: This revision was merged to the branch mainline in revision 4975.
  • Revision ID: andrew.bennetts@canonical.com-20100115035820-ilb3t36swgzq6v1l
Merge lp:bzr.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/testing.txt
173
173
 
174
174
Per-implementation tests are tests that are defined once and then run
175
175
against multiple implementations of an interface.  For example,
176
 
``test_transport_implementations.py`` defines tests that all Transport
177
 
implementations (local filesystem, HTTP, and so on) must pass.
178
 
 
179
 
They are found in ``bzrlib/tests/*_implementations/test_*.py``,
180
 
``bzrlib/tests/per_*/*.py``, and
181
 
``bzrlib/tests/test_*_implementations.py``.
 
176
``per_transport.py`` defines tests that all Transport implementations
 
177
(local filesystem, HTTP, and so on) must pass. They are found in
 
178
``bzrlib/tests/per_*/*.py``, and ``bzrlib/tests/per_*.py``.
182
179
 
183
180
These are really a sub-category of unit tests, but an important one.
184
181
 
 
182
Along the same lines are tests for extension modules. We generally have
 
183
both a pure-python and a compiled implementation for each module. As such,
 
184
we want to run the same tests against both implementations. These can
 
185
generally be found in ``bzrlib/tests/*__*.py`` since extension modules are
 
186
usually prefixed with an underscore. Since there are only two
 
187
implementations, we have a helper function
 
188
``bzrlib.tests.permute_for_extension``, which can simplify the
 
189
``load_tests`` implementation.
 
190
 
185
191
 
186
192
Doctests
187
193
~~~~~~~~
198
204
 
199
205
 
200
206
Shell-like tests
201
 
~~~~~~~~~~~~~~~~
 
207
----------------
202
208
 
203
209
``bzrlib/tests/script.py`` allows users to write tests in a syntax very close to a shell session,
204
210
using a restricted and limited set of commands that should be enough to mimic
287
293
 
288
294
  $ cat file
289
295
 
 
296
The actual use of ScriptRunner within a TestCase looks something like
 
297
this::
 
298
 
 
299
        def test_unshelve_keep(self):
 
300
                # some setup here
 
301
                sr = ScriptRunner()
 
302
                sr.run_script(self, '''
 
303
        $ bzr add file
 
304
        $ bzr shelve --all -m Foo
 
305
        $ bzr shelve --list
 
306
        1: Foo
 
307
        $ bzr unshelve --keep
 
308
        $ bzr shelve --list
 
309
        1: Foo
 
310
        $ cat file
 
311
        contents of file
 
312
        ''')
 
313
 
290
314
 
291
315
 
292
316
.. Effort tests
353
377
        KnownFailure should be used with care as we don't want a
354
378
        proliferation of quietly broken tests.
355
379
 
 
380
ModuleAvailableFeature
 
381
        A helper for handling running tests based on whether a python
 
382
        module is available. This can handle 3rd-party dependencies (is
 
383
        ``paramiko`` available?) as well as stdlib (``termios``) or
 
384
        extension modules (``bzrlib._groupcompress_pyx``). You create a
 
385
        new feature instance with::
 
386
 
 
387
            MyModuleFeature = ModuleAvailableFeature('bzrlib.something')
 
388
 
 
389
            ...
 
390
            def test_something(self):
 
391
                self.requireFeature(MyModuleFeature)
 
392
                something = MyModuleFeature.module
 
393
 
 
394
 
356
395
We plan to support three modes for running the test suite to control the
357
396
interpretation of these results.  Strict mode is for use in situations
358
397
like merges to the mainline and releases where we want to make sure that