Page History

...

If you’re writing a test class meant to be re-used as a super class (e.g RepositoryTestCase, suffix it with TestCase; this will for other tests, make it actually abstract and that should suffice to exclude it from execution. (it would otherwise fail, because it likely has no @Test methods). Another pattern we've used in the past (but I'd like to get away from it) is suffixing with TestCase (e.g RepositoryTestCase).

Methods: since we’re using jUnit 4, there is no need to prefix method names with test. Choose a method name that describes what the test asserts. (fooDoesBarWhenX())

Self tests: if you need to test methods of the test class itself (e.g utility methods that the tests use need to be themselves to validate their behaviour), do that in a method called selfTest(). If there are multiple such test methods, refer to the point above.

If you’re testing a reusable test class, two options:
- don’t suffix it with TestCase, but just with Test and use selfTest() methods.
- if that’s not applicable, FooBarTestCaseSelfTest might seem a little over the top.

If you're testing an abstract class whose name is prefixed with Abstract, follow the same conventions. Name it AbstractFooTest. Add your @Test methods. If the test class isn't abstract, they'll be executed. Specify in the Javadoc if its meant to be reused for implementing tests for concrete Foo implementations. If the tests need a concrete an instance of Foo, implement it as an inner class of your tests and explicitly don't implement the methods that AbstractFoo doesn't implement and aren't relevant to the test (throw some exception) - this should be very easily generated and maintained by your IDE even if the interface of AbstractFoo changes.

In some cases, we also want to test external libraries. In particular, when a certain Magnolia feature relies on a specific behavior of such library, we might want to assert that it indeed does behave the way we think it does, and that it continues on doing so in their future releases. For such cases, selfTest methods can help, but if we’re testing more than that, then we can envision FooBarLibTest classes (where FooBar is the class under test, and LibTest is the suffix) - we’re “testing the libs of FooBar”.

...