Don’t Over Test

We write tests that deliver real value while managing the potential high carrying cost associated with them. This lesson emphasizes the strategic decisions involved in choosing what to test, explores the ideal scenario of relying solely on system tests, and provides an example of writing a controller test to address specific needs—all while considering the value each test assertion brings to quality assurance. The importance of ensuring tests are coupled with the right components is highlighted, and we also provide insights into leveraging assertion libraries for confidence checks before actual test assertions.

Tests aren’t an end unto themselves. They have a potentially high carrying cost. Thus, we need to be careful that every test we write serves a purpose and delivers real value.

In the previous end-to-end example section, we explicitly did not write tests for validations in the model test because those validations were covered by the test of our service class. That was a strategic decision to reduce the carrying cost of tests without sacrificing coverage. This applies to our controller tests, too. Ideally, we would not need controller tests at all, because our system tests would tell us if our controller code is broken. That said, the more type conversions our controllers must perform, the more likely we are to need to test them.

In the previous section, we had to make our system test reach into the database in order to get coverage of the price conversion logic. That would be better tested in a controller test, so let’s do that now.

Writing a controller test

There are two approaches we can take. One would be to mock WidgetCreator and assert that it received converted values. The other would be to not mock anything and assert what ends up in the database.

One approach isn’t more correct than the other—they both boil down to what we want our test to be coupled with. Because the API for creating widgets with WidgetCreator is relatively simple, we are going to avoid mocking and assert on the database. Here’s what the test looks like: