Unit testing
============

This section covers the basis of unit testing and the technical
implementation of it used on the SEGA robot components.

Introduction
------------

Working on a large piece of code can be frustrating because errors can
sneak into the smallest parts of you code ruining your precious program.
A solution is to divide the big program into multiple parts which can do
seperate tasks, these parts of a program are also called units. But how
can you easily tell every one of this units is doing it's job. That's
what unit testing is for. It makes developing software fun again.

How does it work?
-----------------

The main idea of unit testing is that every unit is a seperate,
functional component. Therefore it can be individually tested, so it
doesn't need the 'bigger' picture of the program itself and can be used
really early in the development process. That's one of the key
advantages of unit testing, because problems can be detected sooner,
which speeds up the time working on debugging. The next thing you have
to keep in mind if you are about to do some unit testing is that you
have to isolate testing from actual source code. This may sound rather
strange, but unit testing has more in common with specifications of an
piece of software than the actual software. Here is why, because you
want to test the behaviour of your software, not your code. This is an
interresting view, because you can specify the behaviour that you want
and implement it later. If you test then succeeds, you'll not only know
that your code is correct, but you'll also know that it does what you
want it to do.

Technical details
-----------------

Now on to the interresting stuff, the module used to test the SEGA
robots units. Because we use Python as our programming language, it was
not difficult to choose the built-in unit tester called unittest to use
as the unit tester for our SEGA robot. However, even for our crude unit
testing it was quite sufficient and maybe even more powerful then we
may think. There are three kinds of tests possible that covers the most
common errors. First you must test for giving too little parameters, to
test that the parser doesn't work when you give too few parameters.
Second you must test for the format of the parameters, to test that that
the parser doesn't accept wrongly formatted data. Last but not least,
the testing for wrong data values. These are the hardest errors to
debug, but with unit testing it should be a lot easier. Of each test we
used three unique iterations of each sort of test, so we came to a total
of nine tests per unit. 

.. automodule:: test_sensor
    :members:

.. automodule:: test_sonar
    :members:

.. automodule:: test_laser
    :members:

.. automodule:: test_odometry
    :members:

.. automodule:: test_wheels
    :members: