While much of the content was beyond my comprehension, I found Kevlin Henney’s article “Test Precisely and Concretely” article at Medium.com to be elucidating and enjoyable. Kevlin is known for his efficacious brevity in software and so it should come as no surprise that this translates to his writing. He comes right out of the gate with a strong opening sentence:
“It is important to test for the desired, essential behavior of a unit of code, rather than for the incidental behavior of its particular implementation.”
– Kevlin Henney @ https://medium.com/analytics-vidhya/test-precisely-and-concretely-810a83f6309a
While the first half of the quote describes the obvious end result that we as programmers are aiming to achieve, our desire to do write effective tests certainly doesn’t preclude us from making the mistake of the latter. There may be diminishing returns on the profundity of this statement but, as an amateur programmer who has only just begun to learn proper software testing, I’ve found myself writing software tests that give true outcomes but do not necessarily verify that the program itself performs accurate and verifiable calculations. For instance, when I was creating additional instances of an object in a recent assignment I was testing to see if additional objects were consecutively constructed in the sense that memory was allocated for it but I was not properly verifying that the objects upon their creation were given consecutive, uniquely identifying numbers which is where the real meaning of its creation lay. Simply put, it was the software testing equivalent of begging the question.
From my understanding, Kevlin’s prescription to the aforementioned issue is to understand that the conditions which are necessary for your test to pass are not always sufficient for their real use cases and born from this is the realization that programmers ought to more carefully examine the literal meanings of the postconditions they’re testing for. Furthermore, he states an accurate condition does not make for a good test, a “good test should be comprehensible and simple enough that you can readily see that it is correct.” In the spirit of the article, and perhaps even Kevlin himself, I will avoid verbosity and recommend that everyone check out what makes for a good software test here.
From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.