Introduction

Writing test code and running these tests in parallel is best practice. It can also be a useful tool to help define your code's purpose more precisely.

General guidelines:

• Each test unit should focus on a tiny bit of functionality and prove it correct.

• Each test should run independently, regardless of the order that they are called in. The implication of this rule is that each test must be loaded with a fresh dataset and may have to do some cleanup afterwards.

• Try hard to write tests that run fast, on the order of a few milliseconds.

• Always run the full testing suite both before and after a coding session. This will give you confidence that you did not break anything.

• Use hooks that run tests before pushing to a repository.

• Long test function names are fine, as they are never called explicitly. test_square_of_number2() and test_square_negative_number2() are fine and descriptive, which is important as test names are displayed when a test fails.

• As with all of your code, write descriptive and clear comments.