This discussion is archived
2 Replies Latest reply: Dec 19, 2012 1:24 AM by TPD-Opitz-Consulting-com RSS

Junit help

880368 Newbie
Currently Being Moderated
I have not used Junit earlier. I have to test a project which primarily depends on five user codes. There could be two methods that need to be tested. These primary methods call several sub methods based on some conditions. Please note other than the user code there are several other parameters that are given as input. These also play a role in determining how the methods branch. What would be the best approach to test this project.

Thanks,
  • 1. Re: Junit help
    rp0428 Guru
    Currently Being Moderated
    >
    I have not used Junit earlier. I have to test a project which primarily depends on five user codes. There could be two methods that need to be tested. These primary methods call several sub methods based on some conditions. Please note other than the user code there are several other parameters that are given as input. These also play a role in determining how the methods branch. What would be the best approach to test this project.
    >
    The first step is to create a matrix that shows all of the possible code paths and the parameters and conditions that need to be set to take each path.

    Then you will need to create a test for each possible code path. You should also have tests for invalid parameters to make sure the code does something meaningful when it doesn't get the input it is expecting.
  • 2. Re: Junit help
    TPD-Opitz-Consulting-com Expert
    Currently Being Moderated
    877365 wrote:
    I have not used Junit earlier. I have to test a project which primarily depends on five user codes.
    What do you mean by <i>user codes</i>? I guess classes.
    at first you should ensure a proper project folder hirarchie as sugested by the maven Project
    http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

    The point is that you create different folders for the production code and the test code. This way you can have Test in the same package as the class under test wich will ease access to some service methods.

    The point of unittesting is that you focus on on class only. If the class currently under test uses objects of other classes you should mock those other objects (replace them with a simpler implementation. This reduces the complexity of your tests. Also: if you need to change one of the other classes you do not neet tho change tests testing dependend objects.

    The problem here is that your production code must be pepared to allow this replacment. The easiest way is to create package private getter methods:
    class ToBeTested {
      public void methodToBeTested(){
         new SomeOtherClass().aMethod();
     }
    }
    //turns to:
    class ToBeTested {
      public void methodToBeTested(){
         createObjectOfSomeOtherClass().aMethod();
     }
     SomeOtherClass createObjectOfSomeOtherClass() { return new SomeOtherClass();}
    }
    Most IDEs have an automated refactoring to do that.
    Your test would look like this:
    class MyTestOfToBeTestedTest{
      @Test
      public void shouldPassThis(){
        new ToBeTested () {
           @Override SomeOtherClass createObjectOfSomeOtherClass() { return new SomeOtherClass(){
                public void aMethod(){
                   // do something specific for this particular test.
                   // eg. return a literal value...
                }
           };}
        }.methodToBeTested();
      }
    } 
    This could (and most likely should) also be done via some Mocking framework (JMock/mockito).

    bye
    TPD

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points