Wednesday, October 7, 2009

Testing Stage

Now that we finished developing our robocode project, it is now time for some testing. Testing a project may sound easy at first, but in fact, it is one of the most difficult tasks when it comes to project development. As a part of our class exercise, we were asked to design some test cases that would be useful when we actually go and create the test cases later on. I must say that it was not easy to come up with an ideal test case for my lab partner's robocode project. It took me a good half an hour of thinking and brainstorming to finally come up with an idea that may work well for his project.

Designing test cases for my own robot also was a difficult task. It seemed to me that in order for my robot to pass an acceptance test, it must at least beat the strongest of the sample robots, that is, Walls. I simply created an acceptance test case where my robot and Walls battle with each other for 5 rounds. If my robot successfully beats Walls 5 matches in a row, then it passes the first phase of my acceptance test. Another acceptance case would be a very similar one, but my robot now has to beat Tracker. I chose to implement Tracker because this robot does not have a set routine movement like Walls and some of the other sample robots. Passing my two acceptance case would mean that the robot is capable of beating a robot that is strong and has a set routine movement, and is also capable of beating a robot that does not have a set routing movement.

My first behavior test was rather simple. Since my robot does somewhat involve random movements, and it is programmed to move forward until it hits a wall, it should at least touch 3 of the 4 walls in the battlefield before the match ends. My first behavior test checks just that. My other behavior test checks to see if the robot is actually moving perpendicular to the enemy. This part of the test was difficult to implement because by the time onTurnEnd() method is called, the target robot may have moved to a another position. I resolved this issue by giving the robot a much larger range for its 'perpendicular movement'. For instance, moving 45 degree angle towards the enemy would still be considered as a 'perpendicular movement'.

For my Unit tests, I basically tested to see if the part of my code that controls the turning of the robot is working correctly. I also had some difficulties implementing this test case because the robot only turns about 10 degrees per turn. This makes it difficult to keep track of the robot's turn rate and how much it had already turned. My other Unit test case checks for the function that takes the robot out of the corners. This is done simply by checking whether the robot does a 90 degree turn sometime during a battle.

After finishing up all of my test cases, I continued to improve my project by using a tool called Emma. Emma is a tool that provides a greater insight to your code, by allowing you to view which part of your code is actually being ran and which part isn't. This tool is helpful especially when it comes to testing and I hope to use this tool for my future projects as needed.

My Robocode project with the above test cases can be downloaded Here.

No comments:

Post a Comment