Understanding what code coverage represents, how to effectively apply it, and how to avoid its pitfalls will give you an unprecedented understanding of how unit tests may or may not be covering you from sneaky defects.

You’ve drunk the XP cool-aide and made a concerted effort to actively unit test your code. After awhile, however, you may find yourself wondering how good are those tests? Are they actually covering the code adequately? Understanding what code coverage represents, how to effectively apply it, and how to avoid its pitfalls will give you an unprecedented understanding of how those unit tests may or may not be covering you from sneaky defects. We’ll talk code based coverage and specification-based coverage and we’ll look at the tools available to gather these metrics in both the open-source and commercial worlds. Additionally, we’ll examine the notion of mutation testing and its affect on code coverage.

The knowledge of how to effectively spot smelly code and replace it with proven patterns will ultimately lead to a more stable, maintainable and elegant code base.

Often times, candidate code for refactoring is based upon a source file's smell, which its spotting can take time to acquire and is largely based upon subjective determinations. The proper use of code metrics, such as Cyclomatic Complexity, Fan-In, Fan-Out, and Depth of Inheritance can also facilitate the discovery of candidate code which is in need of refactoring.

For example, Cyclomatic Complexity is adept at spotting methods containing a high degree of conditional logic, which, consequently, can be replaced with polymorphism as elaborated in Martin Fowler's seminal work, Refactoring with the Replace Conditional with Polymorphism pattern. Additionally, excessively deep hierarchy trees create problematic testing targets, which can be broken out into separate objects with Fowler's Replace Inheritance with Delegation and Collapse Hierarchy patterns. Fan-In and Fan-Out are quite effective at pinpointing brittle code, which can be refactored into a more stable state with a plethora of patterns including Extract Hierarchy and Extract Class.

No one will argue that JUnit has positively affected the quality of thousands of Java applications around the world. JUnit’s simplicity and ease of use ushered in a whole new era of code quality; however, as many developers have found, its simplicity has also limited its use. TestNG was designed from the ground up to overcome some of JUnit’s limitations; moreover, TestNG’s features make it a great tool to complement your JUnit tests.

In this session we’ll learn about TestNG’s flexible fixture model, its test categorization capability, dependent methods, and TestNG’s powerful parametric testing facility. We’ll also see how both TestNG and JUnit can play together in a build process.