Testing suites are usually (but not always) written as small Junit test harnesses, which are committed to source control. That test harness can even be linked into task tracking systems to show evidence that you tested adequately, as below.
/**
* check that XML is created in the correct format (WXGGTL-1528)
*/
@Test
public void testCreateXml() throws Exception
{
:
Junit tests tend to hang around on a project so future developers can also test that they have not accidentally broken anything. For added realism, Junit tests can execute the code in the context of the entire solution, using a fully populated database and mock services.
Something to think about
Files that are likely to change together should be kept together, so my preference is to keep the Junit test harness with the same name as the original class, in the same package; industry standard places them in completely separate folders where compile errors can more readily be ignored. If Junit tests were named with the same prefix as the original class, in the same package, they would appear next to each other in IDE file lists. e.g.
FileMobProvider.java
FileMobProviderTest.java
ComponentTreeCache.java
ComponentTreeCacheTest.java
FileComponentProvider.java
FileComponentProviderTest.java
Using this naming and location convention, refactors of code are easier and you can easily see which classes are covered by tests.
However for most development, follow the industry standard for projects that others will need to maintain. Define unit tests in separate source locations.
Tip: Even a small main() method in the class is better than no test at all.
