UnitTesting

Automatic, relentless, testing is often advocated by ExtremeProgramming? folks. I am certainly one of those folks. Though I haven't followed my own advice when it comes to robot development. Shame on me. The main reason is that I don't really know how to do it effectively. I know that Crippa has unit tests for some of his robot code, so maybe he can elaborate on the subject some. -- PEZ

Googling on the subject I found that PeterLindberg? on Oops has code for an (old) robot with some UnitTesting in place: https://oops.se/cgi-bin/wiki?PeterLindberg%2FFoofy Maybe Peter finds his way to this wiki some day and can explain the why's and how's for us. After all, he's one of the ExtremeProgramming? authorities in Sweden. -- PEZ

The, among robocoders, often used Java IDE - [Eclipse], has the [JUnit] framework integrated. Which should be useful. Anyone with experience of this@ -- PEZ

JUnit is a superb tool I use it everyday. I am a big devotee if the Extreme Programming approach which basically advocates the creation of your unit tests before you create your code.
JUnit is a Java test framework which allows you to write & run unit tests against the methods on your Java classes. It allows you to test that each individual method on a class is performing as expected.
The tests that you write are themselves Java classes that extend the 'TestCase?' class in JUnit. The execution of these test scripts can be executed automatically by Ant so that you can ensure that any modifications you make to your code do not introduce unexpected results elsewhere :) Hexkid

For effective testing of robocode stuff it is important to keep things seperated, so that you can test small methods. Additionally it helped me a lot to create a RobotMock? class that extends AdvancedRobot and contains some code that simulates the robocode environment. This is neccessary if your code calls anything like getX(), getHeading() or so. I started with basic things like

    public double getX() {
        return 400;
    }

and now the robotMock can move around like a 'real' robot and advanced tests like this are possible:

    public void testGoToFunction?() {
        System.out.println("testing basic goTo funtion");
        // create new robot to reset everything
        r = new RobotMock?();
        m = new Movement(r);
        m.goTo(100, 100);

        while ( r.getDistanceRemaining?() != 0) {
            r.execute();
        }
        assertEquals(100, r.getX(), 3);
        assertEquals(100, r.getY(), 3);         
    }

Not everything is simulated, there are no walls and no enemies but it really helps to find some hidden bugs. vario?

Cool idea! I'll remember that for when I'm starting on my new movement. --Vic

Some versions of Marshmallow had mock methods and mock objects too. -- PEZ

I added some example unit tests for my physics engine here that may be of use when writing your own tests. The purpose of unit tests is to catch bugs anywhere in your system (that you've written tests for) when you make code changes (and run the tests). A project I worked on would do a nightly run of the tests to get a report on the success rate and another tool measured lines of code that the tests touched. The goal was 90-100% code coverage and 100% success rate on tests. Some things that are not practical to test for could include environmental states (running out of memory) and i/o errors. Pretty hard to deliberately reproduce. Anyway .. PEZ perked up at the mention that I'd written 76 unit tests to cover my physics subsystem, and I'm also working on covering other systems (like turret and radar operation) as well. -- Martin Alan Pedersen