372
372
fix for it, or if something works on Unix but not on Windows.
375
Testing exceptions and errors
376
-----------------------------
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.
383
.. TODO: Something about how to provoke errors in the right way?
385
In general we want to test errors at two levels:
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.
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.
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.
376
407
Essential Domain Classes
377
408
########################