Well, yes. And no.
You shouldn’t be using literal values anyway. You should be using constants. And when you use constants everywhere, there is absolutely no point in testing whether a constant actually has the literal value assigned to it. No sense in testing the compiler. After all, if you can’t trust your compiler to get this basic stuff right, why are you using it?
And yet…
Some literals are more important than others. If you change these literals, your whole application could break down. Not literally, it won’t crash, but it will no longer function as expected. Despite you being very diligent in your use of constants in lieu of literals. And you won’t find out about it until hours, days, weeks, maybe even months later.
You find out about it when a client is screaming hell and bloody murder because your software stopped doing what it was supposed to do months back. Right after that important update. And now their computer crashed and they find out that they don’t have any data in their backups of your software. How can that be? Nobody has touched the backup functionality for ages …
Turns out that when adding some new functionality somebody inadvertently and unintentionally changed
const API_BACKUP = 'backup';
into
const API_BACKUP = 'baekup';
Of course this should be covered by integration tests. But integration tests usually take a lot longer than unit tests. When dealing with large code bases often are not part of the developer’s submit checks. And that is hoping that automated integration and regression tests are in place. Quite often integration tests and regression tests are not done by developers if at all… Serving coffee to developers in shops where regression testing is not part of the build or even the release process would leave me bankrupt. I wouldn’t even like to serve coffee to developers in shops where (automated) integration testing is done, but selectively based on the functionality or the units that were touched by a change. Heck, even today someone asked about how to limit the test set because it took so long to run…
Quite apart from the question of integration and regression tests, there is the little matter of the effort involved in addressing the problem once it surfaces. Catching these kinds of “blips” as early as possible helps reduce developer effort. Far easier to solve a failing unit test that pinpoints the cause of the failure than having to figure out why some integration test fell over the next day, or even later or not at all…
So what can you yourself do to prevent the horror scenario described above?
Test a literal against a literal? How pointless can you get?
Ah yes. We don’t want to be pointless.
Still, in the case of literal values that can come from the outside and affect what your software does or how it does it, there absolutely is a point to it. These tests only seem pointless because of their implementation of testing a literal value against the same literal value or – better – testing a constant against its literal value. The point is not in exercising the compiler or the unit test framework, but in guarding against inadvertent and unintentional changes.
Leave a Reply