JUnit 4: Nested tests










1














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.










share|improve this question

















  • 2




    Tests should be written in such a way that there is no dependency between them.
    – Joe C
    Nov 11 at 8:06










  • I know, but there clearly is a dependency and I don't know how to resolve it.
    – a.ilchinger
    Nov 11 at 8:08






  • 2




    It seems that you're concerned about more than one test failing if you mess up with the input and make it invalid. Why? What's the problem in having multiple tests failing? Anyway, JUnit 5 supports nested tests if you really want that. You can also just create multiple test classes.
    – JB Nizet
    Nov 11 at 8:13










  • As far as I know, the order of tests is not guaranteed. So even when testTransform is successful, if test_transformation_1 is a separate test and run before that, it would fail anyway. I don't care how many tests fail, but I care about that all preconditions are met (and a precondition for test_transformation_1 is that testTransform returned something non-null.
    – a.ilchinger
    Nov 11 at 8:19










  • That's something you impose to yourself, and which goes against testing best practices. Tests must not depend on each other. When writing a test, just pretend that no other test exists. Each test must be able to run in isolation. So if a test method needs some input, create that input in the test method itself, or by calling another method creating the input from the test method, or using an @Before method. f two separate tests end up using the same input, and the input is incorrect, then it's a good thing that these two tests fail: they should, since their input is incorrect.
    – JB Nizet
    Nov 11 at 8:25
















1














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.










share|improve this question

















  • 2




    Tests should be written in such a way that there is no dependency between them.
    – Joe C
    Nov 11 at 8:06










  • I know, but there clearly is a dependency and I don't know how to resolve it.
    – a.ilchinger
    Nov 11 at 8:08






  • 2




    It seems that you're concerned about more than one test failing if you mess up with the input and make it invalid. Why? What's the problem in having multiple tests failing? Anyway, JUnit 5 supports nested tests if you really want that. You can also just create multiple test classes.
    – JB Nizet
    Nov 11 at 8:13










  • As far as I know, the order of tests is not guaranteed. So even when testTransform is successful, if test_transformation_1 is a separate test and run before that, it would fail anyway. I don't care how many tests fail, but I care about that all preconditions are met (and a precondition for test_transformation_1 is that testTransform returned something non-null.
    – a.ilchinger
    Nov 11 at 8:19










  • That's something you impose to yourself, and which goes against testing best practices. Tests must not depend on each other. When writing a test, just pretend that no other test exists. Each test must be able to run in isolation. So if a test method needs some input, create that input in the test method itself, or by calling another method creating the input from the test method, or using an @Before method. f two separate tests end up using the same input, and the input is incorrect, then it's a good thing that these two tests fail: they should, since their input is incorrect.
    – JB Nizet
    Nov 11 at 8:25














1












1








1







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.










share|improve this question













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.







java testing junit






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 11 at 8:00









a.ilchinger

206




206







  • 2




    Tests should be written in such a way that there is no dependency between them.
    – Joe C
    Nov 11 at 8:06










  • I know, but there clearly is a dependency and I don't know how to resolve it.
    – a.ilchinger
    Nov 11 at 8:08






  • 2




    It seems that you're concerned about more than one test failing if you mess up with the input and make it invalid. Why? What's the problem in having multiple tests failing? Anyway, JUnit 5 supports nested tests if you really want that. You can also just create multiple test classes.
    – JB Nizet
    Nov 11 at 8:13










  • As far as I know, the order of tests is not guaranteed. So even when testTransform is successful, if test_transformation_1 is a separate test and run before that, it would fail anyway. I don't care how many tests fail, but I care about that all preconditions are met (and a precondition for test_transformation_1 is that testTransform returned something non-null.
    – a.ilchinger
    Nov 11 at 8:19










  • That's something you impose to yourself, and which goes against testing best practices. Tests must not depend on each other. When writing a test, just pretend that no other test exists. Each test must be able to run in isolation. So if a test method needs some input, create that input in the test method itself, or by calling another method creating the input from the test method, or using an @Before method. f two separate tests end up using the same input, and the input is incorrect, then it's a good thing that these two tests fail: they should, since their input is incorrect.
    – JB Nizet
    Nov 11 at 8:25













  • 2




    Tests should be written in such a way that there is no dependency between them.
    – Joe C
    Nov 11 at 8:06










  • I know, but there clearly is a dependency and I don't know how to resolve it.
    – a.ilchinger
    Nov 11 at 8:08






  • 2




    It seems that you're concerned about more than one test failing if you mess up with the input and make it invalid. Why? What's the problem in having multiple tests failing? Anyway, JUnit 5 supports nested tests if you really want that. You can also just create multiple test classes.
    – JB Nizet
    Nov 11 at 8:13










  • As far as I know, the order of tests is not guaranteed. So even when testTransform is successful, if test_transformation_1 is a separate test and run before that, it would fail anyway. I don't care how many tests fail, but I care about that all preconditions are met (and a precondition for test_transformation_1 is that testTransform returned something non-null.
    – a.ilchinger
    Nov 11 at 8:19










  • That's something you impose to yourself, and which goes against testing best practices. Tests must not depend on each other. When writing a test, just pretend that no other test exists. Each test must be able to run in isolation. So if a test method needs some input, create that input in the test method itself, or by calling another method creating the input from the test method, or using an @Before method. f two separate tests end up using the same input, and the input is incorrect, then it's a good thing that these two tests fail: they should, since their input is incorrect.
    – JB Nizet
    Nov 11 at 8:25








2




2




Tests should be written in such a way that there is no dependency between them.
– Joe C
Nov 11 at 8:06




Tests should be written in such a way that there is no dependency between them.
– Joe C
Nov 11 at 8:06












I know, but there clearly is a dependency and I don't know how to resolve it.
– a.ilchinger
Nov 11 at 8:08




I know, but there clearly is a dependency and I don't know how to resolve it.
– a.ilchinger
Nov 11 at 8:08




2




2




It seems that you're concerned about more than one test failing if you mess up with the input and make it invalid. Why? What's the problem in having multiple tests failing? Anyway, JUnit 5 supports nested tests if you really want that. You can also just create multiple test classes.
– JB Nizet
Nov 11 at 8:13




It seems that you're concerned about more than one test failing if you mess up with the input and make it invalid. Why? What's the problem in having multiple tests failing? Anyway, JUnit 5 supports nested tests if you really want that. You can also just create multiple test classes.
– JB Nizet
Nov 11 at 8:13












As far as I know, the order of tests is not guaranteed. So even when testTransform is successful, if test_transformation_1 is a separate test and run before that, it would fail anyway. I don't care how many tests fail, but I care about that all preconditions are met (and a precondition for test_transformation_1 is that testTransform returned something non-null.
– a.ilchinger
Nov 11 at 8:19




As far as I know, the order of tests is not guaranteed. So even when testTransform is successful, if test_transformation_1 is a separate test and run before that, it would fail anyway. I don't care how many tests fail, but I care about that all preconditions are met (and a precondition for test_transformation_1 is that testTransform returned something non-null.
– a.ilchinger
Nov 11 at 8:19












That's something you impose to yourself, and which goes against testing best practices. Tests must not depend on each other. When writing a test, just pretend that no other test exists. Each test must be able to run in isolation. So if a test method needs some input, create that input in the test method itself, or by calling another method creating the input from the test method, or using an @Before method. f two separate tests end up using the same input, and the input is incorrect, then it's a good thing that these two tests fail: they should, since their input is incorrect.
– JB Nizet
Nov 11 at 8:25





That's something you impose to yourself, and which goes against testing best practices. Tests must not depend on each other. When writing a test, just pretend that no other test exists. Each test must be able to run in isolation. So if a test method needs some input, create that input in the test method itself, or by calling another method creating the input from the test method, or using an @Before method. f two separate tests end up using the same input, and the input is incorrect, then it's a good thing that these two tests fail: they should, since their input is incorrect.
– JB Nizet
Nov 11 at 8:25













2 Answers
2






active

oldest

votes


















0














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.






share|improve this answer






















  • This was probably a bit ill-formulated. Testing init belongs into its own proper test, but it just feels right to me that this init-test is run only once at the start of the whole test class (which in turn guarantees that all following tests operate on a proper initialized member). Of course, one could do initialization for all test methods separately with @Before, but it feels just unclean to me so duplicate that much work (especially when init is a expensive long running operation).
    – a.ilchinger
    Nov 11 at 8:40











  • Let's put it that way: the standard junit practice is to create new instances for each and any test method. Because junit is mainly for unit test. A true unit test can't have a long running init method. Semantically, you know :-)
    – GhostCat
    Nov 11 at 8:43










  • In other words: when you use junit as automation tool for non unit tests, then just do what makes sense and isn't too awkward.
    – GhostCat
    Nov 11 at 8:45










  • After reading all the great input I came to the conclusion that I'm not really doing unit testing. I will refactor my code to make it better testable.
    – a.ilchinger
    Nov 13 at 14:48










  • @a.ilchinger I appreciate that decision, and the quick comeback! You won't regret it (improving your code I mean ;-)
    – GhostCat
    Nov 13 at 14:49


















0














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.







share|improve this answer




















    Your Answer






    StackExchange.ifUsing("editor", function ()
    StackExchange.using("externalEditor", function ()
    StackExchange.using("snippets", function ()
    StackExchange.snippets.init();
    );
    );
    , "code-snippets");

    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "1"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53246854%2fjunit-4-nested-tests%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    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.






    share|improve this answer






















    • This was probably a bit ill-formulated. Testing init belongs into its own proper test, but it just feels right to me that this init-test is run only once at the start of the whole test class (which in turn guarantees that all following tests operate on a proper initialized member). Of course, one could do initialization for all test methods separately with @Before, but it feels just unclean to me so duplicate that much work (especially when init is a expensive long running operation).
      – a.ilchinger
      Nov 11 at 8:40











    • Let's put it that way: the standard junit practice is to create new instances for each and any test method. Because junit is mainly for unit test. A true unit test can't have a long running init method. Semantically, you know :-)
      – GhostCat
      Nov 11 at 8:43










    • In other words: when you use junit as automation tool for non unit tests, then just do what makes sense and isn't too awkward.
      – GhostCat
      Nov 11 at 8:45










    • After reading all the great input I came to the conclusion that I'm not really doing unit testing. I will refactor my code to make it better testable.
      – a.ilchinger
      Nov 13 at 14:48










    • @a.ilchinger I appreciate that decision, and the quick comeback! You won't regret it (improving your code I mean ;-)
      – GhostCat
      Nov 13 at 14:49















    0














    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.






    share|improve this answer






















    • This was probably a bit ill-formulated. Testing init belongs into its own proper test, but it just feels right to me that this init-test is run only once at the start of the whole test class (which in turn guarantees that all following tests operate on a proper initialized member). Of course, one could do initialization for all test methods separately with @Before, but it feels just unclean to me so duplicate that much work (especially when init is a expensive long running operation).
      – a.ilchinger
      Nov 11 at 8:40











    • Let's put it that way: the standard junit practice is to create new instances for each and any test method. Because junit is mainly for unit test. A true unit test can't have a long running init method. Semantically, you know :-)
      – GhostCat
      Nov 11 at 8:43










    • In other words: when you use junit as automation tool for non unit tests, then just do what makes sense and isn't too awkward.
      – GhostCat
      Nov 11 at 8:45










    • After reading all the great input I came to the conclusion that I'm not really doing unit testing. I will refactor my code to make it better testable.
      – a.ilchinger
      Nov 13 at 14:48










    • @a.ilchinger I appreciate that decision, and the quick comeback! You won't regret it (improving your code I mean ;-)
      – GhostCat
      Nov 13 at 14:49













    0












    0








    0






    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.






    share|improve this answer














    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.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Nov 11 at 8:37

























    answered Nov 11 at 8:30









    GhostCat

    87.9k1684144




    87.9k1684144











    • This was probably a bit ill-formulated. Testing init belongs into its own proper test, but it just feels right to me that this init-test is run only once at the start of the whole test class (which in turn guarantees that all following tests operate on a proper initialized member). Of course, one could do initialization for all test methods separately with @Before, but it feels just unclean to me so duplicate that much work (especially when init is a expensive long running operation).
      – a.ilchinger
      Nov 11 at 8:40











    • Let's put it that way: the standard junit practice is to create new instances for each and any test method. Because junit is mainly for unit test. A true unit test can't have a long running init method. Semantically, you know :-)
      – GhostCat
      Nov 11 at 8:43










    • In other words: when you use junit as automation tool for non unit tests, then just do what makes sense and isn't too awkward.
      – GhostCat
      Nov 11 at 8:45










    • After reading all the great input I came to the conclusion that I'm not really doing unit testing. I will refactor my code to make it better testable.
      – a.ilchinger
      Nov 13 at 14:48










    • @a.ilchinger I appreciate that decision, and the quick comeback! You won't regret it (improving your code I mean ;-)
      – GhostCat
      Nov 13 at 14:49
















    • This was probably a bit ill-formulated. Testing init belongs into its own proper test, but it just feels right to me that this init-test is run only once at the start of the whole test class (which in turn guarantees that all following tests operate on a proper initialized member). Of course, one could do initialization for all test methods separately with @Before, but it feels just unclean to me so duplicate that much work (especially when init is a expensive long running operation).
      – a.ilchinger
      Nov 11 at 8:40











    • Let's put it that way: the standard junit practice is to create new instances for each and any test method. Because junit is mainly for unit test. A true unit test can't have a long running init method. Semantically, you know :-)
      – GhostCat
      Nov 11 at 8:43










    • In other words: when you use junit as automation tool for non unit tests, then just do what makes sense and isn't too awkward.
      – GhostCat
      Nov 11 at 8:45










    • After reading all the great input I came to the conclusion that I'm not really doing unit testing. I will refactor my code to make it better testable.
      – a.ilchinger
      Nov 13 at 14:48










    • @a.ilchinger I appreciate that decision, and the quick comeback! You won't regret it (improving your code I mean ;-)
      – GhostCat
      Nov 13 at 14:49















    This was probably a bit ill-formulated. Testing init belongs into its own proper test, but it just feels right to me that this init-test is run only once at the start of the whole test class (which in turn guarantees that all following tests operate on a proper initialized member). Of course, one could do initialization for all test methods separately with @Before, but it feels just unclean to me so duplicate that much work (especially when init is a expensive long running operation).
    – a.ilchinger
    Nov 11 at 8:40





    This was probably a bit ill-formulated. Testing init belongs into its own proper test, but it just feels right to me that this init-test is run only once at the start of the whole test class (which in turn guarantees that all following tests operate on a proper initialized member). Of course, one could do initialization for all test methods separately with @Before, but it feels just unclean to me so duplicate that much work (especially when init is a expensive long running operation).
    – a.ilchinger
    Nov 11 at 8:40













    Let's put it that way: the standard junit practice is to create new instances for each and any test method. Because junit is mainly for unit test. A true unit test can't have a long running init method. Semantically, you know :-)
    – GhostCat
    Nov 11 at 8:43




    Let's put it that way: the standard junit practice is to create new instances for each and any test method. Because junit is mainly for unit test. A true unit test can't have a long running init method. Semantically, you know :-)
    – GhostCat
    Nov 11 at 8:43












    In other words: when you use junit as automation tool for non unit tests, then just do what makes sense and isn't too awkward.
    – GhostCat
    Nov 11 at 8:45




    In other words: when you use junit as automation tool for non unit tests, then just do what makes sense and isn't too awkward.
    – GhostCat
    Nov 11 at 8:45












    After reading all the great input I came to the conclusion that I'm not really doing unit testing. I will refactor my code to make it better testable.
    – a.ilchinger
    Nov 13 at 14:48




    After reading all the great input I came to the conclusion that I'm not really doing unit testing. I will refactor my code to make it better testable.
    – a.ilchinger
    Nov 13 at 14:48












    @a.ilchinger I appreciate that decision, and the quick comeback! You won't regret it (improving your code I mean ;-)
    – GhostCat
    Nov 13 at 14:49




    @a.ilchinger I appreciate that decision, and the quick comeback! You won't regret it (improving your code I mean ;-)
    – GhostCat
    Nov 13 at 14:49













    0














    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.







    share|improve this answer

























      0














      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.







      share|improve this answer























        0












        0








        0






        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.







        share|improve this answer












        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.








        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 11 at 9:50









        isqo

        3616




        3616



























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53246854%2fjunit-4-nested-tests%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Use pre created SQLite database for Android project in kotlin

            Darth Vader #20

            Ondo