Testing – Code a little, test a little

A very efficient paradigm in application development is the “Code a little, test a little” paradigm.

This means that you should not program everything and after you have finished all of you stuff, you start testing everything, but you should program small pieces, test them and then continue with other small pieces.

The second aspect is that all your test code should not be written inside temporary main methods but in persistent test classes (e.g. utilizing JUnit).

To visualise that approach, imagine you have written the following method:

package samples.testing;

public class CharCount {

    public static int get(String sSource, char cChar) {
        int n = 0;
	if(sSource != null)
	    for(int i = 0; i < sSource.length(); i++)
		if(sSource.charAt(i) == cChar)
		    n++;
		return n;
	}
}

After you have finished this method, it is the right moment to test your method.

Most developers will then add a main method for testing purposes and sometimes delete them after performing their tests.

package samples.testing;

public class CharCount {

    public static int get(String sSource, char cChar) {
        int n = 0;
        if(sSource != null)
            for(int i = 0; i < sSource.length(); i++)
                if(sSource.charAt(i) == cChar)
                    n++;
        return n;
    }

    public static void main(String[] saArg) {
        System.out.println(CharCount.get(null, 'x'));
        System.out.println(CharCount.get("aaaxaxx", 'x'));
    }
}

But what is wrong with this approach?

• If this test code is not removed afterwards
  • it bloats the code,
  • for more complex testing code, classes needed only for the tests are referenced and by this have to be deployed,
  • having more and more test code results often in further main methods like “main2”, “anotherMain” but all without an apparent testing purpose,
• If the test code is removed afterwards
  • valuable test code has been removed,
  • no sustainability is mind.

Only few changes are needed to have persistent and valuable test cases (example is based on JUnit 4):

package samples.testing;

import org.junit.Assert;
import org.junit.Test;

public class CharCountTest {

    @Test
    public void test_get_1() {
        Assert.assertEquals(0, CharCount.get(null, 'x'));
        Assert.assertEquals(3, CharCount.get("aaaxaxx", 'x'));
    }
}

This test case class should be stored inside a directory src/test/java like it is proposed by maven/gradle. The “actual” Java classes should be stored inside a directory src/main/java. By this, the test classes are separated by the main classes.

Looks trivial, but if you do so, you have following benefits:

• Your test cases will increase one-by-one over time. After a long period you will then have a bunch of test cases.
• If you have to adjust your existing code, you can ensure that there are no unwished side effects.
• The execution of test cases are “no-brainers”. You can repeatedly execute how often you want.
• By the test cases, you can prove at any time that your code does what it is intended for.
• You need not noticeable more time for the test case classes. You have to test the code anyway with some test code.

If developers are asked for automated test cases, they often nevertheless use the “temporary main method” approach and after the whole application is finished, they start writing test case classes. With this overall approach, writing test cases results in fact into a considerable additional expenses because there has been added an extra step. It is important that the “temporary main method” approach is replaced by writing persistent test cases — with the “Code a little, test a little” paradigm.

So see yourself and review how you test your code.

Happy coding!

0