Robocode with Jacoco Coverage Tool

Please view my previous post concerning robocode :
Robocode : Competative Robot


For this assignment, I ran the java tool Jacoco over my robot WallRunner to discover the coverage of the code. Coverage refers to whether a line of code has executed. As such, this tool will create an html file where coverage is visualized using the colors green, yellow, and red. According to the Jacoco website these are the color meaning :

  • green for fully covered lines,
  • yellow for partly covered lines and
  • red for lines that have not been executed at all.

One important note is 100% coverage does not necessarily mean good code since depending on the tests some lines of code may not run. For example, WallRunner will execute special code when the opponent robot is on the same wall. When WallRunner competes against the robot sample.SittingDuck, the latter code does not run. SittingDuck just sits in one place on the battle field, so unless the SittingDuck somehow is placed on the wall, the latter code will not run. Whereas when WallRunner competes against the robot sample.Walls, the special code will run since Walls will skirt around the wall. Sooner or later Walls will be on the same wall as WallRunner which fulfills the condition of the special code.

My Jacoco test cases are as follows:
1. Moved in the direction of the closest wall, either left or right.
2. Reached the wall.
3. Moved up/down the wall.
4. Find new target after 3 consecutive bullet misses.
5. Check enemy is on the same wall.
6. Beat sample.Walls robot.

All this test cases were easy to implement once I found the setDebugProperty in the robocode.Robot package. Essentially, I used this debug method set values into the debug to use when running JUnit over the code. These debug values are stored into an IDebugProperty array so in the test source code a simple for each loop allowed me to read all the set debug values.

My test cases cover all the basics of my robot strategy. The difference between test case 1 and test case 2 deals with obstructions before hitting the wall. Although the WallRunner may move towards the closest wall, this does not imply that it arrived at the wall since other robots may obstruct WallRunner’s path. Test case 3 dealt with whether WallRunner moves up and down the wall by checking the velocity of the robot. WallRunner never turns around when it hits a wall, but rather moves in the opposite direction, so checking the robot’s velocity would fulfill this test case.

WallRunner was created to participate in large battles, not one on one. In this sense, WallRunner needs to choose a new opponent if it fails to hit its target in order to maximize the amount of points it accumulates. Due to this reason, test case 4 ensures that a new target is found after 3 consecutive bullet misses. One note is that a new target does not necessarily mean that the old target is not chosen again. Rather, the target that it had previous locked on  was released to find a target.

In my previous post on the WallRunner robot, I explained that the weakness of the robot had to do with WallRunner being on the same wall as the enemy, basically an enemy is directly north or south of WallRunner. An enemy in this position will hit WallRunner without fail due to WallRunner’s movement behavior of moving up and down the wall. In response to this, WallRunner tries to ram the enemy while firing with high bullet power. Test 5 ensures that an enemy north or south of WallRunner will be damaged intensively.

This last test case is the most interesting. The reason is the descrepency in the amount of wins that Jacoco reported versus the amount of wins that the gui-based battle reported. In the gui-based battle, WallRunner solidly beat sample.Walls an average of 60% of the time. With 50 battles, I have never seen a win percentage fall below 50%.

With that said, the battles results using Jacoco were appalling to the point that I believe that Jacoco may be affecting the battle outcome. Over a few Jacoco battles, I would only beat sample.Walls 0 out of 10 battles! I could not find the source of the outcome discrepancy, especially since the battles in the gui and the battles in junit are different. Dr. Johnson mentioned that robot placement on Jacoco and the gui may be different which could explain the battle outcome.

One feature of the RobotTestBed class is that the position of the robots may be override. This allows testing based on static position and heading. By setting the position, WallRunner never reached phase 1 which means it never reached the wall. I did a few test with this setting, but it is the same peculiar outcome; WallRunner never reaches phase 1.

Overall the experience with Jacoco was thrilling. Especially, the color coding of the code viewable in an html file. The idea of visually seeing which lines of code has executed is pretty neat way of insuring that all code is tested within the test case. Moreover, this allows programmers to visually see code which is not run, or conditions that are never met.