Before we talk about how a test case could end, let’s recall its canonical structure. It is needed because we will refer to events that can happen in test’s …
Do you write your tests after corresponding production code has been written? Do you run your new test, see it pass, consider the job done and then move on onto the next task?
Here is a thought experiment for you. I hope it will illustrate a problem with this approach …
This is very likely not a new idea. I most probably have seen it somewhere but have since forgotten where. Now I feel as it was my own idea. I wanted to share it.
Any non-trivial software application has a structure with many units of behavior interacting with each other …
Updated 2023-07-06
Recently I realized that there is a common pattern for many testing-like activities performed during daily development cycles. Many of them provide the biggest benefit if their results are reported in an incremental manner, i.e. against individual change requests, rather than against the whole code base.
Examples …
Static analysis is great because it allows to catch many types of issues without the need to run the code. It is not perfect however. When you consider it in the scope of a big evolving project, there dangers not always pointed out by the adopters. The main danger is …
There is one thing that has bothered me about the asymmetry of relation between the production code and the test code. People often say: “Your tests test the production code, and production code ensures the tests are not broken”.
But it did not feel right. Especially after learning the principle …
The ideas below were inspired by rereading of Tom Stuart’s Understanding Computation book, watching Uncle Bob’s Clean Code videos, and my thoughts about the nature of the problems I observe in daily work with certain tests.
In theory, there is a common agreement that simple tests are better …