From 9944385417ffd63d2976f5d86a92f44798a288e6 Mon Sep 17 00:00:00 2001 From: guibog Date: Sat, 21 Apr 2012 21:35:04 +0800 Subject: [PATCH] Adding a bunch on unit tests --- docs/writing/tests.rst | 63 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) diff --git a/docs/writing/tests.rst b/docs/writing/tests.rst index 306c25d..d7fed0a 100644 --- a/docs/writing/tests.rst +++ b/docs/writing/tests.rst @@ -3,6 +3,69 @@ Testing Your Code Testing your code is very important. +Getting used to writting the testing code and the running code in parallel is +now considered a good habit. Used wisely, this method helps you define more +precisely your code's intent and have a more decoupled architecture. + +Some general rules of testing: + +- A testing unit should focus on one tiny bit of functionality and prove it + 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 setUp() and 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. I some cases, test 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 this 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. + +- It is a good idea to implement a hook that runs all test before pushing code + to a shared repository. + +- If you are in the middle of a development 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 comming back to work, you will have a pointer to where you were and get + faster on tracks. + +- 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 piece of code in your project. + +- Use long and descriptive names for testing functions. The style guide here is + slighlty different than that of running code, where short names are often + preferred. The reason is testing functions are never called explicitely. + ``square()`` or even ``sqr()`` is ok in running code, but in testing code you + would has 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. + +- 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 developpers. When + someone will have to work on the code base, runnning and reading the related + testing code is often the best they can do. They will or should discover the + hot spots, where most difficulties arise, and the corner cases. If they have to + add some functionality, the first step should be to add a test and, by this mean, + ensure the new functionality is not already a working path that has not been + plugged in the interface. The Basics ::::::::::