From 1800feb118408ea406e96712b4f9db20023d5813 Mon Sep 17 00:00:00 2001 From: kuyan Date: Mon, 14 Apr 2014 17:08:22 -0700 Subject: [PATCH] Wrap lines at 78 char as much as possible. --- docs/writing/tests.rst | 57 +++++++++++++++++++++--------------------- 1 file changed, 29 insertions(+), 28 deletions(-) diff --git a/docs/writing/tests.rst b/docs/writing/tests.rst index f42d639..d88877c 100644 --- a/docs/writing/tests.rst +++ b/docs/writing/tests.rst @@ -13,52 +13,53 @@ Some general rules of testing: correct. - Each test unit must be fully independent. Each of them must be able to run - alone, and also within the test suite, regardless of the order they are called. - The implication of this rule is that each test must be loaded with a fresh - dataset and may have to do some cleanup afterwards. This is usually - handled by :meth:`setUp()` and :meth:`tearDown()` methods. + alone, and also within the test suite, regardless of the order they are + called. The implication of this rule is that each test must be loaded with + a fresh dataset and may have to do some cleanup afterwards. This is + usually handled by :meth:`setUp()` and :meth:`tearDown()` methods. - Try hard to make tests that run fast. If one single test needs more than a - few millisecond to run, development will be slowed down or the tests will not - be run as often as desirable. In some cases, tests can't be fast because they - need a complex data structure to work on, and this data structure must be - loaded every time the test runs. Keep these heavier tests in a separate test - suite that is run by some scheduled task, and run all other tests as often - as needed. + few millisecond to run, development will be slowed down or the tests will + not be run as often as desirable. In some cases, tests can't be fast because + they need a complex data structure to work on, and this data structure must + be loaded every time the test runs. Keep these heavier tests in a separate + test suite that is run by some scheduled task, and run all other tests as + often as needed. - Learn your tools and learn how to run a single test or a test case. Then, when developing a function inside a module, run this function's tests very often, ideally automatically when you save the code. - Always run the full test suite before a coding session, and run it again - after. This will give you more confidence that you did not break anything in - the rest of the code. + after. This will give you more confidence that you did not break anything + in the rest of the code. -- It is a good idea to implement a hook that runs all tests before pushing code - to a shared repository. +- It is a good idea to implement a hook that runs all tests before pushing + code to a shared repository. -- If you are in the middle of a development session and have to interrupt your work, it - is a good idea to write a broken unit test about what you want to develop next. - When coming back to work, you will have a pointer to where you were and get - back on track faster. +- If you are in the middle of a development session and have to interrupt + your work, it is a good idea to write a broken unit test about what you + want to develop next. When coming back to work, you will have a pointer + to where you were and get back on track faster. - The first step when you are debugging your code is to write a new test pinpointing the bug. While it is not always possible to do, those bug catching test are among the most valuable pieces of code in your project. -- Use long and descriptive names for testing functions. The style guide here is - slightly different than that of running code, where short names are often - preferred. The reason is testing functions are never called explicitly. +- Use long and descriptive names for testing functions. The style guide here + is slightly different than that of running code, where short names are + often preferred. The reason is testing functions are never called explicitly. ``square()`` or even ``sqr()`` is ok in running code, but in testing code you would have names such as ``test_square_of_number_2()``, - ``test_square_negative_number()``. These function names are displayed when a - test fail, and should be as descriptive as possible. + ``test_square_negative_number()``. These function names are displayed when + a test fails, and should be as descriptive as possible. -- When something goes wrong or has to be changed, and if your code has a good - set of tests, you or other maintainers will rely largely on the testing suite - to fix the problem or modify a given behavior. Therefore the testing code will - be read as much as or even more than the running code. A unit test whose - purpose is unclear is not very helpful is this case. +- When something goes wrong or has to be changed, and if your code has a + good set of tests, you or other maintainers will rely largely on the + testing suite to fix the problem or modify a given behavior. Therefore + the testing code will be read as much as or even more than the running + code. A unit test whose purpose is unclear is not very helpful is this + case. - Another use of the testing code is as an introduction to new developers. When someone will have to work on the code base, running and reading the related