18. RoboTesting

In class we've entered the testing phase of our Robocode projects. This was quite a ramp up from the previous few class sessions, which were mostly focused on ensuring that Ant and Eclipse worked properly and were properly configured.

Download the Leonganisa Testing Project (Eclipse)

Tests Implemented through JUnit:

• Assurance01 - Can the robot beat Corners 90% of the time
• Assurance02 - Can the robot beat both VelociRobot and Crazy at least 40% of the time (in a 3-way battle with the robot coming in first)
• Behavioral01 - Does the radar stay locked on a stationary enemy robot at least 90% of the time using the current scanning algorithm
• Unit01 - Does the proportional firepower method calculate the correct values
• Unit02 - Does the hypotenuse calculation function used to get the length of the battlefield's diagonal calculate correctly?

A few observations:

• The Assurance tests by far were the easiest to create, since we were given a template/example. Unit tests also were fairly easy to implement as well. Since they involved simply plugging in relevant values that prove the calculations are done properly.
  
  
• Behavioral tests by far took the most amount of time. In our behavioral tests we were given a parent class called RobotTestBed, which incidentally was written by our professor (after tracking it down on the google code site). What makes the behavioral tests so difficult is the fact that 1) the saved snapshots of bullets and robots can be a tad unpredictable and 2) the snapshots only offer limited insight into certain variables and methods. For example, the onScannedEvent method in the Robot class allows one easy access to the bearing of a scanned enemy robot. The Robot snapshot, however, has no such helper method, so a bearing must be computed by hand using trigonometric functions.
  
  
• The test cases are somewhat limited. I think it tests two of the major aspects of my robot, but due to the cumbersome nature of testing a battle only simple tests were able to be implemented. E.g., the behavioral test was done with SittingDuck rather than a moving robot.
  
  
• After running JaCoCo, it found that my tests covered 100% of my robot code. I think this may have been a byproduct of running the battles (10 rounds each) through JUnit, which allowed all the code to run all the way through.
  
  
• As for redesigning my robot to ensure that testing is easier, modularizing calculation methods makes it infinitely easier to create tests for them. Also, coming up with the tests beforehand (as well as the requirements) and shaping the robot according to these guidelines would definitely have made things much easier.