Interview Questions and Answers

This is an interesting question.

The technical answer is no. There is no need to write one test class for each every class that need to be tested. One test class can contain many tests for many test target classes.

But the practical answer is yes. You should design one test class per test target class for low level basic tests. This makes your test classes much easier to manage and maintain. You should write separate test classes for high level tests that requires multiple target classes working together.

A JUnit 4.4 test class contains a @Before method, an @After method and multiple @test methods. When calling a test runner to run this test class, the runner will execute those methods in a specific order giving the test class an execution life cycle like this:

@Before
@Test XXX1
@After

@Before
@Test XXX2
@After

When a method is declared as "private", it can only be accessed within the same class. So there is no way to test a "private" method of a target class from any test class.

To resolve this problem, you have to perform unit testing manually. Or you have to change your method from "private" to "protected".

Or if it is not possible to convert any of the above ways, you can test private method by using PowerMock partialMock.

As a method is declared as "protected", it can only be accessed within the same package where the class is defined. To test a "protected" method of a target class, you need to define your test class in the same package as the target class.

No, just test everything that could reasonably break. Keep in mind NullPointerException which occurs maximum.

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.

You need to follow the below logics:

* 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!

You should write unit test before writing the code if you are a TDD (Test-Driven Development) believer. Test-first programming is practiced by only writing new code when an automated test is failing.

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 gaining momentum these days compared to writing tests after the code.