Quite a few software engineering organizations split their sets of automatic tests into two or more suites. Decisions to start certain suites may be tied to engineers’ actions, such as a commit, a pull request, a merge, a release, a change of dependencies, etc. Collectively I will call these suites …
Invisibly but firmly, quality of tests make or break software projects. The production code brings money today. But it is the quality of its accompanying test suite that ensures tomorrow’s production code keeps bringing money going forward.
Let’s talk about some routines that people should perform from time …
I’ve been using test smells from Gerard Meszaros’ xUnit Patterns when reviewing pull requests for a while now. It is a good addition to the regular code smells (see e.g. Marcel Jerzyk’s catalog, although I am usually using a different set).
While code smells are usually applied …
“What/who tests the tests?” This question arises at some point while learning Test-Driven Development (TDD). If every piece of production code ends up tested in the TDD process by construction, does the same apply to the code of the produced tests themselves?
It’s time to go meta.
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 …