Loading ...
Sorry, an error occurred while loading the content.

RE: [XP] Unit Testing RoboCode Robots

Expand Messages
  • Erik Meade
    I went the Mock object route for my bot. An advanced acceptance test would be to fight a mob of raptures:
    Message 1 of 1 , Nov 7, 2001
    • 0 Attachment
      I went the Mock object route for my bot. An advanced acceptance test
      would be to fight a mob of raptures:

      http://robocode.turbochicken.com/BotDetail.jsp?id=15&tln=topDownloads

      --
      Erik Meade emeade@...
      Senior Consultant Object Mentor, Inc.
      http://www.junit.org


      > -----Original Message-----
      > Date: Tue, 6 Nov 2001 13:23:41 -0800 (PST)
      > From: Robert Sartin <sartin@...>
      > Subject: Unit Testing RoboCode Robots
      >
      > OK, for fun, some of us want to design some RoboCode
      > (http://robocode.alphaworks.ibm.com) robots and play them.
      >
      > Before I head off on this effort (on Monday night), I'd like to throw
      > together some ideas on testing. RoboCode is a framwork for building and
      > running robot tanks that compete against each other in a simulated
      > playing field. To write a Robot, one subclasses the Robot or
      > AdvancedRobot class and supplies one or more methods. The run() method
      > is critical as it is called once per turn and calculates the moves. A
      > number of other methods provide for notifications that this Robot hit
      > something or one of its bullets hit something.
      >
      > The [Advanced]Robot is normally called by a play manager and the tests
      > will likely need to replace that manager. Many of the actions taken by
      > a Robot are regrettably handled by methods on the superclass (Robot or
      > AdvancedRobot, methods that do things like move the robot, rotate the
      > gun, fire a bullet) rather than by delegation to the play manager.
      >
      > I'm thinking the best way to deal with this now is created a
      > TestableRobot and TestableAdvancedRobot that perform as I would
      > normally use a Mock Object. These test classes would need to disable
      > the instrumentation when not being used in test mode. Then we can use
      > the instrumentation to verify that our robots do the expected thing
      > under various predefined circumstances.
      >
      > Anybody have any other/better ideas?
      >
      > Of course, the true (acceptance) test is how many other robots it can
      > kill....
      >
      > Regards,
      >
      > Rob
    Your message has been successfully submitted and would be delivered to recipients shortly.