5 Software Testing Principles

A crash is when your competitor’s program dies. When your program dies, it is an “idiosyncrasy.” Frequently, crashes are followed with a message like “ID 02.” “ID” is an abbreviation for idiosyncrasy and the number that follows indicates how many more months of testing the product should have had.

—Guy Kawasaki

Earlier chapters in this book took a very pragmatic approach to design and deploy unit tests. I took a deep look at all the JUnit 5 capabilities and at the architecture of both JUnit 4 and JUnit 5 and demonstrated how to migrate between the two versions. This chapter steps back to look at the various types of software tests and the roles they play in the application life cycle.

Why would you need to know all this information? Unit testing is not just something you do without plans and preparations. To become a top-level developer, you need to contrast unit tests with functional and other types of tests. Functional testing simply means that you evaluate the compliance of a system or component with the requirements. When you understand why unit tests are necessary, you need to know how far to take your tests. Testing in and of itself is not the goal.

5.1   The need for unit tests

5.1.1   Allowing greater test-coverage

5.1.2   Increasing team productivity

5.1.3   Detecting regressions and limiting debugging

5.1.4   Refactoring with confidence

5.1.5   Improving implementation

5.1.6   Documenting expected behavior

5.1.7   Enabling code coverage and other metrics

5.2   Test types

5.2.1   Unit testing

5.2.2   Integration software testing

5.2.3   System software testing

5.2.4   Acceptance software testing

5.3   Black-box vs. white-box testing

5.3.1   Black-box testing

5.3.2   White-box testing

5.4   Summary