Behaviour over structure
Jan 16, 2023
We, developers, often forget why we even exist. We quite often don't remember that our purpose is not to write software, but to solve problems. Those come in different forms, but can be generalized as "we need to start doing this", "we need to stop doing this" or "we need to do this differently". Those "do" and "doing" are the key, whatever "this" is. It's the behaviour our software exhibits that is most important, almost everything else is secondary.
Tests organization and naming
Jul 22, 2021
As our system grows, so will our test suites. For our production code, we have learned techniques to keep it maintainable. For example, we try to structure our logic into sub-aspects, put them in specific locations and give the units meaningful names. We want to achieve the same for our tests. One of the main goals is that a developer - or generally speaking, the person who has to maintain the test - knows where to find which test. We also want to understand as quickly as possible what the test is for and what might be the reason for a failing test.
Jul 20, 2021
Spring is a great project, it helps a lot with common, usually mundane, tasks. But it's not always unicorns and rainbows. Too much Spring in tests can cause a few issues like long execution time and fragility. Here, I'm showing how to avoid such pitfalls.
Jul 5, 2021
In our previous posts, we focused on why and how we write tests. In most of our projects, there will be many of those tests. In the last post about tests granularity, we additionally stated that there usually will be different kinds of tests, on different levels of granularity. That leads to our next topic: which kinds of tests do we need and what is the ideal mix of them?
Familiarity - friend or foe (part 2)
Apr 26, 2021
I continue to see some negative sides to familiarity, this time how it might prevent us from finding better, but not obvious solutions
Oct 22, 2020
In two previous posts we discussed the benefits of automated tests and the properties of a good test. So far we were trying to avoid differentiating the tests in any way. This time we want to address one way how tests can be classified: tests granularity.
Anatomy of a Good Test
Sep 23, 2020
In our last post, we focused on why we should write tests and what value they provide. This time we will go far more technical and take a look at a single test. We will show what makes a test a good one and describe desired and unwanted properties. Interestingly enough, all those properties hold, no matter how isolated or integrated the test is. This already gives us a hint that all tests are alike, we should remember that. Unfortunately, as the topic is very broad, we will have to skip some aspects that play a role when we’re talking about test suites. We will get back to them in one of our next posts.
Why You Should Write Automated Tests
Aug 27, 2020
This blog post gives an overview of the most common benefits gained by writing automated tests. It starts in a place where most of the projects we’ve seen so far are: tests are written as a last step of the development process. Then it shows additional benefits that could be gained if we all gave the tests a bit more focus and care.
Iteration 9 - custom functions
Aug 24, 2020
In WebCalc's ninth iteration I'm enabling users to define their own functions
Familiarity - friend or foe
Oct 8, 2019
Familiarity has two sides. On one, it is quite beneficial, you know the ways, the tools, the pitfalls and it all enables you to work fast. But at the same time, it can make you blind to mistakes you're doing or violations of processes or good practices.