JUnit: 6 Test Cases for FiringDock

A year ago, I totally disagreed when my co-worker mentioned the fact he loves about programming in Java is the ability to build test cases. What is a test case? Every time I code, I compile and verify the result, isn't that called testing? On the first day of ICS613, I got brighten up a little bit when the professor, Dr. Philip Johnson, demonstrated JUnit for FuzzBuzz. Still, more questions came up on how to extend from testing a few lines of code to a large package and also for a web application.

Started from created FiringDock for the first robocode tournament to distributed the high-level package called FiringDock 1.0 with QA tools, I included six test cases in this pacakage. There are two types of test:

Acceptance test: simply verify the victory against the sample robots, in which I chose Crazy and Walls.

TestFiringDockVersusCrazy: Make sure that the FiringDock every round.

TestFiringDockVersusWalls: FiringDock can at least win 50% over the Walls.

Behavioural test: verify the robot's strategy, which include the following test:

TestFiringDockBulletHitEnemy: verify that in each round the bullet hit enemy at least 7 times.

TestFiringDockBulletPower: verify that FiringDock uses the most bullet power for the still target.

TestFiringDockMoveEachFire: verify that FiringDock always moves after each firing.

TestFiringDockMovement: verify that each round FiringDock randomly moves at least 6 times.

Actually, I didn't have any problem building the acceptance test because there's an example provided in the robocode-pmj-decruzer. However, I've spent quite a long time for the behavioural test. I've struggled for a while thinking of what type of strategy I want to test for. Though, I could think of some cases, I was limited to what I can do with the RobotTestBad. This got me confused between the functionality between extends Robot and RobotTestBed. Actually with RobotTestBed ther are not so much properties exists because it just capture the snapshot to the robot after each turn. For instance, to check the bullet's power, I actually used the change of energy as an indicator.

Along with coding the test case, I also split some code into sub-class as I came across an issue of how could I test everything at once. This was part of my bad coding behaviour as I usually throw everything in one place.

Next, I ran emma, code coverage tool, and I got a pretty good result. I also verified the pacakage with the QA tools before created a new package.

Overall, there are lots of improvement in this package both on the coding style and the robot's behavior. I've learnt a lot from the thought process of determine the test case to redesign the package for testability and then build it. Also, this process encourage me to search for IDE tool that fit for building database-driven web site instead of using modern text editor-based tool (eg. Dreamweaver). Fortunately, I found the Eclipse PHP IDE as an open source project which is very ideal for my current project. Hopefully, my coding behaviour will change and I will be able to design a better system for reseachers at the University of Hawaii Sea Grant College Program.

To download the distributed package with test cases, click here.