JUnit Questions and Answers
All downloads are temporary disabled so please wait and check later we are updating pdfs.
JUnit Questions and Answers: Submit Your Question
Call the TestRunner to run the test under the debugger.
When the test fails again, The debugger will suspend the execution and start the debug mode.
Now you are ready to use debugger commands to find the code issue that causing the fail.
How you configure this depends on the debugger you prefer to use.
Most Java debuggers provide support to stop the program when a specific exception is raised.
Good tests tell you how to best design the system for its intended use. They effectively communicate in an executable format how to use the software. They also prevent tendencies to over-build the system based on speculation. When all the tests pass, you know you're done!
Whenever a customer test fails or a bug is reported, first write the necessary unit test(s) to expose the bug(s), then fix them. This makes it almost impossible for that particular bug to resurface later.
Test-driven development is a lot more fun than writing tests after the code seems to be working. Give it a try!
* If a method is not returning anything through the "return" statement (void method), it may return data through its arguments. In this case, you can test the data returned in any argument.
* Else if a method is not returning any data through its arguments, it may change values of its instance variables. In this case, you can test changes of any instance variables.
* Else if a method is not changing any instance variable, it may change values of its class variables. In this case, you can test changes of any class variables.
* Else if a method is not changing any class variable, it may change external resources. In this case, you can test changes of any external resources.
* Else if a method is not changing any external resources, it may just doing nothing but holding the thread in a waiting status. In this case, you can test this waiting condition.
* Else if a method is not holding the thread in waiting status, then this method is really doing nothing. In this case, there is no need to test this method. :-)
By design, the tree of Test instances is built in one pass, then the tests are executed in a second pass. The test runner holds strong references to all Test instances for the duration of the test execution. This means that for a very long test run with many Test instances, none of the tests may be garbage collected until the end of the entire test run.
Therefore, if you allocate external or limited resources in a test, you are responsible for freeing those resources. Explicitly setting an object to null in the tearDown() method, for example, allows it to be garbage collected before the end of the entire test run.
If this is true, the JUnit runner should be improved to stop building all test instances before executing any tests. Instead, the JUnit runner should just take one test at a time, build an instance of this test, execute the test, and release the test when the execution is done.
Be practical and maximize your testing investment. Remember that investments in testing are equal investments in design. If defects aren't being reported and your design responds well to change, then you're probably testing enough. If you're spending a lot of time fixing defects and your design is difficult to grow, you should write more tests.
If something is difficult to test, it's usually an opportunity for a design improvement. Look to improve the design so that it's easier to test, and by doing so a better design will usually emerge.
For larger systems, you may just run specific test suites that are relevant to the code you're working on.
Run all your acceptance, integration, stress, and unit tests at least once per day (or night).
If you're using Eclipse, be sure to check out David Saff's continuous testing plug-in.
Don't forget to use this as a learning opportunity. Perhaps the defect could have been prevented by being more aggressive about testing everything that could reasonably break.
Or perhaps there are other places in the application that have the similar code that might break too.
First example is the getX() method. Suppose the getX() method only answers the value of an instance variable. In that case, getX() cannot break unless either the compiler or the interpreter is also broken. For that reason, don't test getX(); there is no benefit. The same is true of the setX() method, although if your setX() method does any parameter validation or has any side effects, you likely need to test it.
1. Select File > New > JUnit Test Case.
2. Select the arrow of the button in the upper left of the toolbar. Select JUnit Test Case.
3. Right click on a package in the Package Explorer view in the Java Perspective, and select JUnitTestCase.
4. Click on the arrow of the icon in the toolbar. Select JUnit Test Case.
5. You can create a normal Java class as shown in the Eclipse tutorial, but include junit.framework.TestCase as the super class of the test class you are creating.
1. You can right click on the test case class or test suite class and select Run As > JUnit Test.
2. You can select a test case or suite and click the arrow on the icon or select Run from the toolbar, and select Run As > JUnit Test.
3. You can select a test case or suite and click the arrow on the icon or select Run from the toolbar, and select Run... From here you will create a new JUnit test configuration, and name it. You can choose to run a single test case, or run all test cases in a project or folder.