acceptance testing my robocode robot

I'm embarking on an implementation of a robocode robot and my last post on this topic illustrated pushing the robot into a boundary via an adapter so that any code I write can be within my own model.

Before I continue and begin to wire up my robot one thing that strikes me is that I will need to evaluate how well my robot is doing as I change code. Rather than wait for the weekly battle against other robots created by my opponents, I should be able to verify that the changes I make are for the better.

I've therefore decided to start with acceptance testing my robot and doing this up front, so I'm going to park my implementation for the time being and write my first acceptance - I think it should be the most simple one of all:

In a one round battle, fighting against a single robot that does not move, the slayer robot should win.

So how do I go about writing and running this kind of acceptance test?

As I'm the only stakeholder on this project I don't see the need for a BDD or other acceptance framework, so I'm going to roll it in C# in an acceptance testing namespace of my specifications so I need to think about hooking into robocode and running each test.
After much research into what's required, here's what I need to do:

  1. Set up robocode to be able to read a robot from my bin/debug folder
  2. Work out how to run robocode from the command line with the right parameters for a given test
  3. Define a battle for the acceptance test
  4. During an acceptance test, run the robocode process against this battle
  5. Parse a results file and provide results back to my acceptance test

So I'll be tackling each one of these in future posts and once I've set this process up these acceptance tests will become my invariant tests that I'm attempting to give more prominence to in my work.



0 comments: