Unit testing

During the work on the programming tasks, you surely discovered for yourself that testing your code is an important part of the programming. Actually, each function, method, and class shall have its own testing code that helps the programmers ensure that the code does only such things we want it to do.

Wouldn't it be nice if you could approach some pretty large software project and say: “Hey you, big project, test yourself!” A magic spell would be cast: something would go through all the code, find all the tests, check all their results, and presented a nice summary of the whole process. This is exactly one of the gratest contributions of the automated testing.

The Spam filter task is a bit larger than prisoner's dillema. To ensure that you are on the right track to a succesful solution, we prepared a set of tests that you can run at home and check all important aspects of your code. The upload system checks only the final product - spam filter. The provided tests shall check the majority of all the little functions and classes you will use to create the spam filter. If you understand their outputs, you shall get good guidelines to find the places in your code that contain errors or other issues.

For each step in the spam filter task, you will get one or more test files. You can store and run them in the same directory, where you develop your spam filter.

The tests are placed in modules which have names of the form test_xxxxx.py. You will also get some supporting files named tst_xxxxx.py. These modules do not contain any tests, only definitions of auxiliary constants and helper functions, and are imported into the test modules.

Your production code is not allowed to import modules test_xxxxx, or tst_xxxxx. You can certainly study those codes and find an inspiration in them, but you cannot use them as a direct part of your solution because these modules will not be accessible during the final check of your solution.

There are several packages or libraries that allow is to perform automated testing in Python. In the basic Python distribution, usually 2 of them can be found:

• module doctest and
• module unittest.

We chose the second option for implementation of our tests. Module unittest is a Python implementation of de facto standard testing framwork called xUnit.

To test a single particular function or method, it is sufficient to run a single unit test. In later phases of the solution, we would like to run all tests at once. We suggest you to create a batch file with the following contents:

c:\python32\python -m unittest discover .

After its execution, module unittest will search for all the tests in current directory. (Function discover is available from version 3.2.) If you develop in Python 3.1, you can create a batch file containing all the unit tests manually.

There is a whole lot of suggestions of what you shall and shall not do in unit test. In practice, it is suggested e.g. not to work with files on the disk in unit tests, because it brings a lot of unwanted phenomena (tests are slow, race conditions, etc.).

We have intentionally decided to break several of these rules for the sake of clarity. For example, we create directories with fake testing email messages on the disk during the tests, which we subsequently delete. This way, you have the chance to actually see the real files on the disk when you debug your code using debugger.

We hope that advances programmers among you will forgive us.