Agfdhyk

I have a data transformation class which I want to test. The interface ITransformer is given. The class looks like this:

public class MyDataTransformer implements ITranformer {



    public MyDataTransformer() {}



    @Override

    public void init(String args) throws Exception {

        if (args.length == 0)

            throw (new Exception("bad input"));



        // do initialization

    }



    @Override

    public byte transform(byte input) {

        try {

            return transform_internal(input);

        } catch (Exception e) {

            return null;

        }

    }



    private static byte transform_internal(byte input) throws Exception {

        // do something

    }

}

And this is the test class I currently have:

public class TransformerTest {



    private MyDataTransformer transformer;



    @BeforeClass

    public void setUp() {

        String args = new String[4];

        // set args



        try {

            transformer = new MyDataTransformer();

            transformer.init(args);

        } catch (Exception e) {

            fail(e.getMessage());

        }

    }



    @Test

    public void testTransform() {

        byte input = read_input(); // omitted here for brevity



        byte output = transformer.transform(input);

        // this only tests if "valid" data was returned, but does not look into it

        assertNotNull("Transformation failed", output);



        // these 2 test some properties of the result data and should be separate tests

        assertTrue("transformation step 1 failed", test_transformation_1(output);

        assertTrue("transformation step 2 failed", test_transformation_2(output);

    } 

}

There are two things I struggle with when it comes to testing.

First, how do I properly test the init method only once? Semantically, init belongs into the @BeforeClass block, but this block is not a proper test.

Second, how can I separate test_transformation_1 out into its own test, yet make sure that this is run only after the testTransform completed successfully (otherwise it is not sensible to run this test on invalid input).

To me, it feels like nesting tests would solve both problems, hence the title of the question. This example however may grow and I might add independent tests which do not need nesting and I'd like to keep it as simple as possible.

What makes you think that "semantically" it belongs into BeforeClass?! Semantically, testing the expected behavior of any method belonging to your class under test... belongs into a test method. Not into methods that prepare resting.

A meaningful init method would need to receive per test case setup data. So, if at all, you would have a field MyDataTransformer underTest that gets init'ed in a @Before method. With parameters that later allow proper testing.

Testing that the init method behaves as expected and throws up belongs into a distinct, nicely named @Test method.

Beyond that, you can force Junit to execute test cases given some order (for example lexicographical sorted). That isn't exactly great practice, but sometimes an okay solution to such ordering issues.

there is no link between a function called init and it should be run only once in a unit test.It could also be run before each function.

it is a bad practice to make a test depends on another,you have to separate their testing context otherwise this is gonna lead to nightmares, if a second test depends on an other, it could fail because the first one has changed the state shared between them.therefor you are slowing yourself finding the regression root cause,and even if you decide to order alphabetically your tests,what if you were many working on the same project and someone named his test differently ... you see it is also bad.

the purpose of nested classes is to group tests by domain ,hence,enhance the quality and maintainability of your test. What i see in your design is just one domain.

Off-topic:
it is bad practice to throw the general Exception class, for the sake of maintainability, create a specialized one.
also i see a smell in your code, why do you return inside a catch,normally,you must log the exception or throw it and the return must be outside, also, to save you some headaches in the future, return an empty array instead of null.