Testing the engine

General policy for testing

We like automated tests (just like, not love). If done right, they save a lot of testing time. Currently we are developing functionality tests (user-oriented) for each of the tickets we code as a requisite for accepting any pull request into our master branch. We don't require unit tests for each piece of code, but at least a a test class for each piece of functionality should be created for any pull request to be merged in.

Introduction to creating tests.

However, creating tests for a game engine is quite tricky since you actually need to launch the game engine in order to test things. The class MockGame does just that: launches a no-ui version of the game engine, and let's you test things.

So, broadly speaking, the first step to creating a test consists of creating an instance of MockGame. This is usually done in a setUp() method tagged with @Before:

@Before
public void setUp() {
     // MockGame is usually defined as an attribute of the test
     // class so it can be reused in different test methods
     mockGame = new MockGame();
     // Retrieve the GameLoop, which will give you access to the 
     // current scene for adding actors, and many other interesting 
     // things. GameLoop is also defined most of the times as an 
     // attribute of the class.
     gameLoop = mockGame.getGameLoop();
}

Then, create your test methods. A good way to think of a test method is that it should have a very clear objective that is easy to describe. Instead of testing a lof of different scenarios in one test, try to divide them logically in separate methods. To identify that any particular method in your class is a test method, tag it with @Test. All methods tagged with @Test are executed by junit when the whole project gets tested.

Within your test methdos you will have to interlace the code that does the testing with a call to mockGame.act() to force updates in the mock engine. Otherwise any changes you make to the game state with your testing code will have no effect. Towards the end of your method, you will need to make the final assertions that actually check if the results of your operations are those you expected. An example:

@Test
 public void yourTestMethod(){
   // Always force a first update on the game to load the first scene
   mockGame.act();
  
   // Write your testing code calling mockGame.act() whenever you need the engine to get updated.
   ...pieceOfCode1...
   mockGame.act();
   ...pieceOfCode2...
   mockGame.act();
   ....

   //Finally, make as many assertions as you need to check the results are OK.
   assertEquals(object1, object2); //Object1 and object 2 should be equal
   assertTrue (condition that should be true);
   assertFalse(condition that should be false);
   assertNull (object that should be null)
   ...
}

Tips

1. EqualsBuilder for testing object equality. While testing it is quite usual to have the need of checking equality of objects. That means you need to write the equals() method for the class of those objects. Instead of doing so, use Apache's EqualsBuilder, which is part of the common-lang package. This class, which is available for coding in eAdventure2 as it has been added through a maven dependency (only for testing), will let you compare two objects just using reflection, without needing to handcraft the equals method.

   • Usage: EqualsBuilder.reflectionEquals(object1, object2);
   • Known issues: This method does not work well if object1 and object2 are java.util.List. In those cases, you should iterate over the list and use EqualsBuilder on each pair of objects contained in list1 and list2.

Examples

If you are about to start writing your own tests, the best you can do is to see some test examples:

• For the schema
• For renderers, a good example is the FrameAnimationTest
• For effects