Testing: It's not as easy as it sounds!

On this assignment, we have to create different test cases for our Robocode robots. These test cases are Acceptance, Behavioral, and Unit tests. Acceptance test are tests that simply checks if our robot beats one of the sample robots in a given number of rounds. Behavioral test are tests that makes sure our robot’s movement, firing, or targeting are doing what they are intended to do. Lastly, there are Unit tests which verify our robots’ method output given different inputs. The later might have to be written after our robots’ code is "refactored".

We were given a heads up on the what these test are when we described possible test cases on our partner’s robot during lab. Describing these tests was easy enough but little did I know that implementing these seemingly easy test was going to be so hard.

For my acceptance test I used SittingDuck and Corners against WallEE. As for my behavioral test, I created a test to make sure my robot turns in the right direction since WallEE is based on sample walls, it turns left towards and perpendicular to the first wall it sees. Lastly my unit test consists of testing how my robot fires a bullet with power proportional to the distance of the enemy. This was the hardest to implement because I did not have the methods that was in accessible in WallEE such as determining the distance between WallEE and its enemy. This was a great opportunity for me to modify my code in order to have a “testable” block of code, which I did but to no result. It was hard for me to “refactor” that specific code so that I can test it and at the same time preserve its original function. So I did most of the distance calculation within my test which I know is not a good idea because it does not preserve the encapsulation of my code.

I don't feel that my tests adequately ensure the quality of my robot because I only have four test cases. Two of which are acceptance and one of each behavioral and unit tests. What I would have done is to test my other movement strategy which is WallEE treading back to where the enemy was to get another shot.

After implementing the test cases for the junit, I ran Emma which is another build tool that measures and reports Java code coverage. Here are the results:

• Class - 86%
• Method - 88%
• Block -84%
• Line - 85%

From these result I learned that Emma will doesn't really look at TestBedAssert which accounts for the missing coverage. Some of the code in WallEE's class was not run, onHitRobot, since most of my test enemy is a sittingDuck robot.

All in all this assignment was hard but very rewarding. The practice we get from creating not just only any test cases but good test cases will help us write codes that are both easy to understand and easy to test.

The new distribution file of WallEE can be downloaded here.