Testing evaluates software behavior with defined inputs, execution conditions, and expected results. Automated tests reduce bugs and expose regressions, but cannot prove a program is bug-free. Use them alongside static analysis and code review rather than treating any one technique as sufficient. section 1.4 section 1.8
Unit tests matter only when they actually execute and make meaningful checks. A faulty test can pass while testing nothing, leaving a regression undetected. Assertions should express the intended behavior precisely; weak checks such as non-nullness or inequality can pass despite an incorrect result. section 10.0 section 10.8
Build tests around observable behavior and failure-prone boundaries:
- Cover every branch of an if chain, and run loops with two or more iterations when repeated execution can change state. section 3.12
- Test string-processing functions even with a simple case; argument-order mistakes can compile and run without throwing exceptions. section 6.10
- Test utility methods thoroughly and reuse them instead of repeating a fragile inline formula, especially when inputs may be negative. section 4.5
- Cover UI messages with unit tests to catch library-call mistakes that produce visibly wrong output. section 9.1
Avoiding a test that silently skips assertions
A test that catches an expected exception and returns exits before later assertions run. Use assertThrows() for the exceptional operation, then keep follow-up verification reachable; if the checks concern separate behavior, split them into separate tests. section 10.4 section 10.8
public void testMapping() throws Exception {
E e = new E();
e.mymap.put("a.b", "a");
e.mymap.put("c.e.g", "b");
try {
getDs().save(e);
} catch (Exception ex) {
return; #1
}
Assert.assertFalse("Should have got rejection…", true);
e = getDs().get(e);
Assert.assertEquals("a", e.mymap.get("a.b")); #2
Assert.assertEquals("b", e.mymap.get("c.e.g"));
}
The return in the catch block makes the later map assertions unreachable whenever save() throws, so the test appears successful without verifying them. section 10.4
assertThrows() states the expected failure directly and leaves subsequent restoration checks visible and executable. section 10.4
Property-based testing performs random operations and checks invariants such as absence of unexpected exceptions or preservation by read-only operations. When a property fails, the framework can replay and shrink the operation sequence. Coverage tools report executed lines, instructions, or branches, but high coverage is costly near 100% and remains an incomplete quality measure. section 1.4 section 1.8
