Strategy for writing test cases (using jUnit and EclEmma)

1. Write different testing functions for testing different cases with respect to the requirements; validate it with respect to the requirements.
2. Complexity, Branch and Line coverage, of functions under test, must be 100%.
3. Method coverage, of class under test, must not be less than the number of methods going to be tested.
4. Instruction coverage should be greater than or equals to 85%.
5. Write single test case for each getter and setter functions in entity level.

Though 100 percent test coverage might not be possible still you can always try to reach near it.

1. Write your test cases in requirement analysis and design phase itself. This way you can ensure all the requirements are testable.
2. To ensure maximum test coverage divide application into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts.
3. While writing test cases, write test cases for intended functionality first i.e. for valid conditions according to requirements. Then write test cases for invalid conditions. This will cover expected as well unexpected behavior of application under test.
4. Start testing the application by intend of finding bugs/errors. Don’t think beforehand that there will not be any bugs in the application. If you test the application by intention of finding bugs you will definitely succeed to find those bugs.
5. Write test cases to all conditions for loops , if-else etc
6. Use EclEmma for checking test coverage, by using this tool we can analyze coverage for each methods separately. Also will be able to ensure the line coverage and instructions coverage for these methods. This enables us to write more test cases for methods which have low coverage.

Coverage Counters

Instruction Coverage:

The smallest unit that counts are single Java byte code instructions. Instruction coverage provides information about the amount of code that has been executed or missed.
Branches Coverage:

Branch coverage which is also called as Decision coverage report s the true or false of the conditions like if-else, case and the ternary operator (? :) statements. For an "if" statement, decision coverage will report whether the "if" statement is evaluated in both true and false cases, even if "else" statement doesn't exist.
Line Coverage:
No coverage: No instruction in the line has been executed (red background)
Partial coverage: Only a part of the instruction in the line have been executed (yellow background)
Full coverage: All instructions in the line have been executed (green background)
Line coverage = lines covered / total number of executable lines
Method Coverage:

 A method is considered as executed when at least one instruction has been executed. Each non-abstract method contains at least one instruction. A method is considered as executed when at least one instruction has been executed.
Complexity Coverage:

JaCoCo(Since version 2.0 EclEmma is based on the JaCoCo code coverage library) calculates cyclomatic complexity for each non-abstract method and summarizes complexity for classes, packages and groups. Cyclomatic complexity is the minimum number of paths that can, in (linear) combination, generate all possible paths through a method. Thus the complexity value can serve as an indication for the number of unit test cases to fully cover a certain piece of software. Complexity figures can always be calculated, even in absence of debug information in the class files.
The formal definition of the cyclomatic complexity v(G) is based on the representation of a method's control flow graph as a directed graph:
v(G) = E - N + 2
Where E is the number of edges and N the number of nodes. JaCoCo calculates cyclomatic complexity of a method with the following equivalent equation based on the number of branches (B) and the number of decision points (D):
v(G) = B - D + 1
Based on the coverage status of each branch JaCoCo also calculates covered and missed complexity for each method. Missed complexity again is an indication for the number of test cases missing to fully cover a module. Note that as JaCoCo does not consider exception handling as branches try/catch blocks will also not increase complexity.
Example test coverage report: