Chapter 4. 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

This chapter covers

Earlier chapters in this book took a pragmatic approach to designing and deploying unit tests. This chapter steps back and looks at the various types of software tests and the roles they play in the application’s lifecycle.

Why would you need to know all this? Because unit testing isn’t something you do out of the blue. In order to become a well-rounded developer, you need to understand unit tests compared to functional, integration, and other types of tests. Once you understand why unit tests are necessary, then you need to know how far to take your tests. Testing in and of itself isn’t the goal.

4.1. The need for unit tests

The main goal of unit testing is to verify that your application works as expected and to catch bugs early. Although functional testing accomplishes the same goal, unit tests are extremely powerful and versatile and offer much more than verifying that the application works. Unit tests

4.2. Test types

4.3. Black box versus white box testing

4.4. Summary