Q: Why Test?
A: Most developers spend the majority of their time not writing code but debugging and maintaining it. Unit tests are one of the best ways to minimize unnecessary time spent on both. Testing also helps document your code. Finally, we use a passing unit test suite as one of the criteria for accepting pull requests.
Q: What software is used to test?
A: Terasology uses JUnit 4 for its automated test suite. It also uses Mockito for mocking/stubbing in special situations for which a dependency is too expensive or unreliable to bring into a test suite - for example, network activity or OpenGL.
An IDE is highly encouraged for running tests, as most support JUnit. On Eclipse, for example, you can quickly run a single test by right-clicking on the test method declaration and selecting "Run As -> JUnit Test". You can give this command a shortcut key of your choice to make it even faster.
Q: How often should I Use Mocks or Stubs?
A: Rarely. If you find yourself using Mockito a lot, you may want to consider refactoring your code to be more modular.
Q: What should I test?
A: Ideally, every line of code that you want to merge should be backed by a Unit test. However, there are exceptions, such as getters/setters. The general rule is that the more likely your code is to fail or change, the more important it is to have test coverage.
Q: When should I run the full test suite?
A: On pulling any changes and before making any pull requests. To save yourself any unpleasant surprises, you should also run the complete test suite after completing any unit of work on the code.
Q: How should I test?
A: Ideally, you should write your tests first. Begin by thinking about what success looks like for the problem you're trying to solve. Then attempt to write a test in code that captures the solution. Then write the code to make the test pass.
Q: What's up with the nested tests and @RunWith(Enclosed.class) ?
A: JUnit supports nested test classes. Our convention is to use a single outer class to test all of the functionality of a given class. Each inner class contains all tests for a single method on the object under test.
For example:
// Don't forget imports
@RunWith(Enclosed.class) public class StringTest { public static class Equals { private String string; @Before public void setUp() { string = "Testing"; } @Test public void returnsTrueGivenDifferentInstanceOfSameString() { assertTrue(string.equals(testing)); } } public static class IndexOf { private String string; @Before public void setUp() { string = "Testing"; } @Test public void returnsNegativeOneGivenNotFound() { assertEquals(-1, string.indexOf("foobar")); } } }
More examples of this style can be found in the tests folder under the org.terasology.model.inventory package.
Finally had the time to wikify this - http://wiki.movingblocks.net/Main/UnitTesting - thanks! :-)