~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/HACKING

  • Committer: Aaron Bentley
  • Date: 2007-07-17 13:27:14 UTC
  • mfrom: (2624 +trunk)
  • mto: This revision was merged to the branch mainline in revision 2631.
  • Revision ID: abentley@panoramicfeedback.com-20070717132714-tmzx9khmg9501k51
Merge from bzr.dev

Show diffs side-by-side

added added

removed removed

Lines of Context:
372
372
fix for it, or if something works on Unix but not on Windows.
373
373
 
374
374
 
 
375
Testing exceptions and errors
 
376
-----------------------------
 
377
 
 
378
It's important to test handling of errors and exceptions.  Because this
 
379
code is often not hit in ad-hoc testing it can often have hidden bugs --
 
380
it's particularly common to get NameError because the exception code
 
381
references a variable that has since been renamed.
 
382
 
 
383
.. TODO: Something about how to provoke errors in the right way?
 
384
 
 
385
In general we want to test errors at two levels:
 
386
 
 
387
1. A test in ``test_errors.py`` checking that when the exception object is
 
388
   constructed with known parameters it produces an expected string form.
 
389
   This guards against mistakes in writing the format string, or in the
 
390
   ``str`` representations of its parameters.  There should be one for
 
391
   each exception class.
 
392
 
 
393
2. Tests that when an api is called in a particular situation, it raises
 
394
   an error of the expected class.  You should typically use
 
395
   ``assertRaises``, which in the Bazaar test suite returns the exception
 
396
   object to allow you to examine its parameters.  
 
397
 
 
398
In some cases blackbox tests will also want to check error reporting.  But
 
399
it can be difficult to provoke every error through the commandline
 
400
interface, so those tests are only done as needed -- eg in response to a
 
401
particular bug or if the error is reported in an unusual way(?)  Blackbox
 
402
tests should mostly be testing how the command-line interface works, so
 
403
should only test errors if there is something particular to the cli in how
 
404
they're displayed or handled.
 
405
 
375
406
 
376
407
Essential Domain Classes
377
408
########################
633
664
variable, so some bugs are not detected right away.
634
665
 
635
666
 
 
667
The Null revision
 
668
-----------------
 
669
 
 
670
The null revision is the ancestor of all revisions.  Its revno is 0, its
 
671
revision-id is ``null:``, and its tree is the empty tree.  When referring
 
672
to the null revision, please use ``bzrlib.revision.NULL_REVISION``.  Old
 
673
code sometimes uses ``None`` for the null revision, but this practice is
 
674
being phased out.
 
675
 
 
676
 
636
677
Getting Input
637
678
=============
638
679
 
693
734
should be only in the command-line tool.
694
735
 
695
736
 
 
737
 
 
738
Displaying help
 
739
===============
 
740
 
 
741
Bazaar has online help for various topics through ``bzr help COMMAND`` or
 
742
equivalently ``bzr command -h``.  We also have help on command options,
 
743
and on other help topics.  (See ``help_topics.py``.)
 
744
 
 
745
As for python docstrings, the first paragraph should be a single-sentence
 
746
synopsis of the command.
 
747
 
 
748
The help for options should be one or more proper sentences, starting with
 
749
a capital letter and finishing with a full stop (period).
 
750
 
 
751
All help messages and documentation should have two spaces between
 
752
sentences.
 
753
 
 
754
 
696
755
Writing tests
697
756
=============
698
757