Hey EMMA we got more than bugs we got waste! Testing and Coverage with JUnit and EMMA

So you are checking over your work as you should always do: checking to see if that english report is missing a reference, if you remembered to carry that 1 in the math problem, trying to see if using the area of a sphere gets what you want to get; for everyone double checking their work is a challenge with patience and seeing beyond the narrow tunnel of understanding you dug for yourself to see if the tunnel can hold the weight of other people.

After getting use to the powers of Automated Assurance (see last blog post), we were asked to create test cases to check to make sure that our programmed Robocode Robots (You may remember mine, GunAryos, from this entry) do what we think they would do and not something that we thought it was suppose to do but not what we expected. In order to fulfill this challenge we were given information about JUnit, a testing framework that works with java and our coding to create test situations one can use to check functionality.

I don't know about anyone else's robot but my immediate dilemma became, "How do you test something that is suppose to move randomly?" Luckily for me we were allowed to do 2 Acceptance Tests (tests which check if we meet up to the general standards of beating an opponent in robocode combat), while 4 others had to be behaviorial (does it doe what it should) or unit tests (does a method give out what it is suppose to).

Acceptance tests were easy enough, I mentioned before that GunAryos does rather well against the sample robots, well enough to pass the standard line we can draw for an acceptance test. By using the sample bots for this I can assure that I don't make my robot any worse with any modifications.

Behaviorial tests are difficult, based on my design, GunAryos has no specific travel goal, and with JUnits limited ability to obtain information directly from the program, I had to think of some behaviors that occur almost guaranteed. This is where I thought of the important points, GunAryos always turns after hitting a wall one of the few times it stays still in combat. Tests for that went smoothly.

Next I thought about how I had given GunAryos a more refined ramming system that allows it to ram the opponent during shots and trying to maintain pressure on them. Because this action was such a specific trackable instance, specifically because the ramming damamge becomes a ramming score after the battle is over, I set up to ensure that in combat GunAryos would ram its opponent. This was also a success, and howed it was more than just lucky shots.

The next behaviorial test came after considering what else GunAryos does. It was from this that I figured out gunAryos' design made its main form of battle and scoring. The behavior became to check if it dealt mostly gun damage rather than the ram damage documented earlier. This worked well to show that the main form of attack isn't ramming like the previous test implied but shooting.

Lastly came my unit test, where I tested to ensure that my random functions using math that I used for all my angle turning moments was giving me results within the realm I had set for it. This two passed ok.

We were given access to EMMA with our Ant installation (see last entry again) and from EMMA we can see exactly how much of our code was used by the JUnit test, a rather interesting way to add review onto the testing process. With EMMA checking my code (the test code anyway) it always gave 90% to 99% for how much of my test code is used, only showing partial usage when I used an assertTrue instead of assertEquals, which was necessary to simplify some tests. I was rather happy with this result, knowing that as a whole (with the untested java file for GunAryos), the code came out to about 66% covered by EMMA, meaning that not much of my code would have been in use. But knowing a lot of my code is being used and no errors were brought up during the testing and error check period, I am happy.

Testing in general is hard work, when it comes to making things one focuses on the goal and the path you have chosen, but testing it can literally be like trying to walk all the other pathes next to it and seeing if the path you chose breaks down somewhere. Many hours were put into understanding JUnit and getting those tests to make sense, but with them I feel like we can make more reliable code. It may have taken awhile but the coding it will save us as a result will probably be a great rounter point. If anything time being a factor and already feeling squished for time with JUnit, I can only imagine the kind of issues a programmer would have without it. For now this version of GunAryos is complete and I might be able to make it even better as I refine the tests and the program itself.

Want to see GunAryos and its test? The lastest distribution can be found here.