14
14
test before writing the code.
16
16
In general, you can test at either the command-line level or the
17
internal API level. See Writing Tests below for more detail.
17
internal API level. Choose whichever is appropriate: if adding a
18
new command, or a new command option, then call through run_bzr().
19
It is not necessary to do both. Tests that test the command line level
20
are appropriate for checking the UI behaves well - bug fixes and
21
core improvements should be tested closer to the code that is doing the
22
work. Command line level tests should be placed in 'blackbox.py'.
19
24
* Try to practice Test-Driven Development. before fixing a bug, write a
20
25
test case so that it does not regress. Similarly for adding a new
48
53
Evolving interfaces
49
54
-------------------
51
We have a commitment to 6 months API stability - any supported symbol in a
52
release of bzr MUST NOT be altered in any way that would result in
53
breaking existing code that uses it. That means that method names,
54
parameter ordering, parameter names, variable and attribute names etc must
55
not be changed without leaving a 'deprecated forwarder' behind. This even
56
applies to modules and classes.
58
If you wish to change the behaviour of a supported API in an incompatible
59
way, you need to change its name as well. For instance, if I add a optional keyword
60
parameter to branch.commit - that's fine. On the other hand, if I add a
61
keyword parameter to branch.commit which is a *required* transaction
62
object, I should rename the API - i.e. to 'branch.commit_transaction'.
64
When renaming such supported API's, be sure to leave a deprecated_method (or
65
_function or ...) behind which forwards to the new API. See the
66
bzrlib.symbol_versioning module for decorators that take care of the
67
details for you - such as updating the docstring, and issuing a warning
68
when the old api is used.
70
For unsupported API's, it does not hurt to follow this discipline, but its
71
not required. Minimally though, please try to rename things so that
72
callers will at least get an AttributeError rather than weird results.
75
Standard parameter types
76
------------------------
78
There are some common requirements in the library: some parameters need to be
79
unicode safe, some need byte strings, and so on. At the moment we have
80
only codified one specific pattern: Parameters that need to be unicode
81
should be check via 'bzrlib.osutils.safe_unicode'. This will coerce the
82
input into unicode in a consistent fashion, allowing trivial strings to be
83
used for programmer convenience, but not performing unpredictably in the
84
presence of different locales.
56
If you change the behaviour of an API in an incompatible way, please
57
be sure to change its name as well. For instance, if I add a keyword
58
parameter to branch.commit - that's fine. On the other hand, if I add
59
a keyword parameter to branch.commit which is a *required* transaction
60
object, I should rename the API - i.e. to 'branch.commit_transaction'.
62
This will prevent users of the old API getting surprising results.
63
Instead, they will get an Attribute error as the API is missing, and
64
will know to update their code. If in doubt, just ask on #bzr.
194
174
may not catch every case but it's still useful sometimes.
200
In some places we have variables which point to callables that construct
201
new instances. That is to say, they can be used a lot like class objects,
202
but they shouldn't be *named* like classes:
204
> I think that things named FooBar should create instances of FooBar when
205
> called. Its plain confusing for them to do otherwise. When we have
206
> something that is going to be used as a class - that is, checked for via
207
> isinstance or other such idioms, them I would call it foo_class, so that
208
> it is clear that a callable is not sufficient. If it is only used as a
209
> factory, then yes, foo_factory is what I would use.
251
In general tests should be placed in a file named test_FOO.py where
216
In general tests should be placed in a file named testFOO.py where
252
217
FOO is the logical thing under test. That file should be placed in the
253
218
tests subdirectory under the package being tested.
255
For example, tests for merge3 in bzrlib belong in bzrlib/tests/test_merge3.py.
256
See bzrlib/selftest/test_sampler.py for a template test script.
258
Tests can be written for the UI or for individual areas of the library.
259
Choose whichever is appropriate: if adding a new command, or a new command
260
option, then you should be writing a UI test. If you are both adding UI
261
functionality and library functionality, you will want to write tests for
262
both the UI and the core behaviours. We call UI tests 'blackbox' tests
263
and they are found in bzrlib/tests/blackbox/*.py.
265
When writing blackbox tests please honour the following conventions:
267
1. Place the tests for the command 'name' in
268
bzrlib/tests/blackbox/test_name.py. This makes it easy for developers
269
to locate the test script for a faulty command.
271
2. Use the 'self.run_bzr("name")' utility function to invoke the command
272
rather than running bzr in a subprocess or invoking the
273
cmd_object.run() method directly. This is a lot faster than
274
subprocesses and generates the same logging output as running it in a
275
subprocess (which invoking the method directly does not).
277
3. Only test the one command in a single test script. Use the bzrlib
278
library when setting up tests and when evaluating the side-effects of
279
the command. We do this so that the library api has continual pressure
280
on it to be as functional as the command line in a simple manner, and
281
to isolate knock-on effects throughout the blackbox test suite when a
282
command changes it name or signature. Ideally only the tests for a
283
given command are affected when a given command is changed.
220
For example, tests for merge3 in bzrlib belong in bzrlib/tests/testmerge3.py.
221
See bzrlib/selftest/testsampler.py for a template test script.
287
226
Currently, bzr selftest is used to invoke tests.
288
227
You can provide a pattern argument to run a subset. For example,
289
to run just the blackbox tests, run::
228
to run just the whitebox tests, run::
291
./bzr selftest -v blackbox
230
bzr selftest -v whitebox
294
233
Errors and exceptions
308
247
Revision 0 is always the null revision; others are 1-based
309
248
indexes into the branch's revision history.
315
The ``Transport`` layer handles access to local or remote directories.
316
Each Transport object acts like a logical connection to a particular
317
directory, and it allows various operations on files within it. You can
318
*clone* a transport to get a new Transport connected to a subdirectory or
321
Transports are not used for access to the working tree. At present
322
working trees are always local and they are accessed through the regular
323
Python file io mechanisms.
328
Transports work in URLs. Take note that URLs are by definition only
329
ASCII - the decision of how to encode a Unicode string into a URL must be
330
taken at a higher level, typically in the Store. (Note that Stores also
331
escape filenames which cannot be safely stored on all filesystems, but
332
this is a different level.)
334
The main reason for this is that it's not possible to safely roundtrip a
335
URL into Unicode and then back into the same URL. The URL standard
336
gives a way to represent non-ASCII bytes in ASCII (as %-escapes), but
337
doesn't say how those bytes represent non-ASCII characters. (They're not
338
guaranteed to be UTF-8 -- that is common but doesn't happen everywhere.)
340
For example if the user enters the url ``http://example/%e0`` there's no
341
way to tell whether that character represents "latin small letter a with
342
grave" in iso-8859-1, or "latin small letter r with acute" in iso-8859-2
343
or malformed UTF-8. So we can't convert their URL to Unicode reliably.
345
Equally problematic if we're given a url-like string containing non-ascii
346
characters (such as the accented a) we can't be sure how to convert that
347
to the correct URL, because we don't know what encoding the server expects
348
for those characters. (Although this is not totally reliable we might still
349
accept these and assume they should be put into UTF-8.)
351
A similar edge case is that the url ``http://foo/sweet%2Fsour" contains
352
one directory component whose name is "sweet/sour". The escaped slash is
353
not a directory separator. If we try to convert URLs to regular Unicode
354
paths this information will be lost.
356
This implies that Transports must natively deal with URLs; for simplicity
357
they *only* deal with URLs and conversion of other strings to URLs is done
358
elsewhere. Information they return, such as from ``list_dir``, is also in
359
the form of URL components.
365
If you'd like to propose a change, please post to the
366
bazaar-ng@lists.canonical.com list with a patch, bzr changeset, or link to a
367
branch. Please put '[patch]' in the subject so we can pick them out, and
368
include some text explaining the change. Remember to put an update to the NEWS
369
file in your diff, if it makes any changes visible to users or plugin
370
developers. Please include a diff against mainline if you're giving a link to
373
Please indicate if you think the code is ready to merge, or if it's just a
374
draft or for discussion. If you want comments from many developers rather than
375
to be merged, you can put '[rfc]' in the subject lines.
377
Anyone is welcome to review code. There are broadly three gates for
380
* Doesn't reduce test coverage: if it adds new methods or commands,
381
there should be tests for them. There is a good test framework
382
and plenty of examples to crib from, but if you are having trouble
383
working out how to test something feel free to post a draft patch
386
* Doesn't reduce design clarity, such as by entangling objects
387
we're trying to separate. This is mostly something the more
388
experienced reviewers need to help check.
390
* Improves bugs, features, speed, or code simplicity.
392
Code that goes in should pass all three.
394
If you read a patch please reply and say so. We can use a numeric scale
395
of -1, -0, +0, +1, meaning respectively "really don't want it in current
396
form", "somewhat uncomfortable", "ok with me", and "please put it in".
397
Anyone can "vote". (It's not really voting, just a terse expression.)
399
If something gets say two +1 votes from core reviewers, and no
400
vetos, then it's OK to come in. Any of the core developers can bring it
401
into their integration branch, which I'll merge regularly. (If you do
402
so, please reply and say so.)
added
removed
HACKING
