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.

Sensor test component

The sensor test component is an extended TestCase component which tests the abstract nature of the Sensor class.

class test_sensor.SensorTest(methodName='runTest')

SensorTest implements a sensor test case

testAbstract()

testAbstract tests that an abstract class like Sensor can never be constructed by calling it’s default constructor

test_sensor.main()

main executes the TestCase suite loaded from the LaserTest class

Sonar test component

The sonar test component is an extended TestCase component which tests various aspects of the Sonar parser which involve give too little data to parse, enough data but in the wrong format or just wrong values.

class test_sonar.SonarTest(methodName='runTest')

SonarTest implements a sonar test case

setUp()

setUp creates the object to be tested in a testSuite

testTooLittleData1()

testTooLittleData1 checks the parsing if the Name and Range isn’t correctly given

testTooLittleData2()

testTooLittleData2 checks the parsing if the Name and Range isn’t correctly given

testTooLittleData3()

testTooLittleData3 checks the parsing if the Name and Range isn’t correctly given

testWrongFormat1()

testWrongFormat1 gives the Name and Range parameter in the wrong format

testWrongFormat2()

testWrongFormat2 gives the Name and Range parameter in the wrong format

testWrongFormat3()

testWrongFormat3 gives the Name and Range parameter in the wrong format

testWrongValue1()

testWrongValue1 provides the wrong values for the Range parameters to test the parsing

testWrongValue2()

testWrongValue2 provides the wrong values for the Range parameters to test the parsing

testWrongValue3()

testWrongValue3 provides the wrong values for the Range parameters to test the parsing

test_sonar.main()

main executes the TestCase suite loaded from the LaserTest class

Laser test component

The laser test component is an extended TestCase component which tests various aspects of the Laser parser which involve give too little data to parse, enough data but in the wrong format or just wrong values.

class test_laser.LaserTest(methodName='runTest')

LaserTest implements a laser test case

setUp()

setUp creates the object to be tested in a testSuite

testTooLittleData1()

testTooLittleData1 checks the parsing if no Name parameter is given

testTooLittleData2()

testTooLittleData2 checks the parsing if no Type parameter is given

testTooLittleData3()

testTooLittleData3 checks the parsing if no Range paramter is given

testWrongFormat1()

testWrongFormat1 gives the ‘Type’ parameter in the wrong format

testWrongFormat2()

testWrongFormat2 gives the Name parameter in the wrong format

testWrongFormat3()

testWrongFormat3 gives the Range parameter in the wrong format

testWrongValue1()

testWrongValue1 provides the wrong values for the Resolution parameters to test the parsing

testWrongValue2()

testWrongValue2 provides the wrong values for the FOV parameters to test the parsing

testWrongValue3()

testWrongValue2 provides the wrong values for the Range parameters to test the parsing

test_laser.main()

main executes the TestCase suite loaded from the LaserTest class

Odometry test component

The odometry test component is an extended TestCase component which tests various aspects of the Odometer parser which involve give too little data to parse, enough data but in the wrong format or just wrong values.

class test_odometry.OdometryTest(methodName='runTest')

OdometryTest implements a odometry test case

setUp()

setUp creates the object to be tested in a testSuite

testTooLittleData1()

testTooLittleData1 checks the parsing if the Pose isn’t correctly given

testTooLittleData2()

testTooLittleData2 checks the parsing if the Pose isn’t correctly given

testTooLittleData3()

testTooLittleData3 checks the parsing if the Pose isn’t correctly given

testWrongFormat1()

testWrongFormat1 gives the Pose parameter in the wrong format

testWrongFormat2()

testWrongFormat2 gives the Pose parameter in the wrong format

testWrongFormat3()

testWrongFormat3 gives the Pose parameter in the wrong format

testWrongValue1()

testWrongValue1 provides the wrong values for the Pose parameters to test the parsing

testWrongValue2()

testWrongValue2 provides the wrong values for the Pose parameters to test the parsing

testWrongValue3()

testWrongValue3 provides the wrong values for the Pose parameters to test the parsing

test_odometry.main()

main executes the TestCase suite loaded from the LaserTest class