5 Software testing principles

 

This chapter covers

  • Examining the need for unit tests
  • Differentiating between types of software tests
  • Comparing black-box and white-box testing

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 designing and deploying unit tests. We took a deep look at JUnit 5’s capabilities and the architectures 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 do you need to know all this information? Unit testing is not something you do without planning and preparation. To become a top-level developer, you need to contrast unit tests with functional and other types of tests. Functional testing simply means evaluating the compliance of a system or component with the requirements. When you understand why unit tests are necessary, you also 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

System software testing

Acceptance software testing

Summary