JUnit testing

The experts say that writing tests for your program will probably take more time than writing code for the program itself. I now know that, the experts are right.

This week I started writing JUnit tests to check certain aspects of my Robocode robot. What seemed like a simple task turned out to be a major challenge. Up till now, I've little experience using JUnit. It's almost like learning a new programming language. There are syntax to learn and different ways of doing things. What made it even more challenging was that my robot was limited in ways that made my imagination grasp at straws when the time came for writing the tests. My robot was very simple and that made testing very difficult. What could you test for if there were no calculations to verify?

I found that writing good tests required a look at three different types of testing. They were acceptance testing, behavioral testing, and unit testing. These three types are essential for testing different aspects of a program. For instance, acceptance testing is a process that requires you to check that the main objective of a program is fulfilled. The behavioral testing requires that an intended action of the program be executed and work reliably. And the unit tests are to check if a certain block of code (like calculating the hypothenuse) correctly outputs the right values.

This was my mindset when I started writing tests for my Bato.1.1. Here are some of the tests I wrote and an explanation. The package with these tests and my robot source code can be downloaded here.


TestBato1

This is an acceptance test to check whether Bato can defeat the robot Crazy ten times in a row.

TestBato2

This is another acceptance test that checked if Bato can defeat the robot SpinBot at least half the time.

TestBato3

This is a behavioral test that checks if Bato is too close to the enemy. It determines through ten rounds if Bato is ever at least 20 pixels away from the enemy robot.


TestBato4

This is another behavioral test that checks if Bato is stuck in a corner. Based on my fighting strategy, I have observed that this could be a problem. So this is a useful test.

With my robot being so simple and lacking in calculations I could not come up with anymore test cases to writeup. The final step was to verify my tests and see if I covered all the possible cases. It was up to the program Emma to tell me if I could do any more. Here are the results.
Emma Coverage summary
class: 75% (6/8)
method: 80% (35/44)
block: 65% (440/682)
line: 64% (112.8/176)

Would any developers out there like to comment on these percentages and how I did?