This post was written for the NCrunch blog. You can find the original here. There are many ways of testing your application or library. The test pyramid provides a good starting point to the most common types of tests—unit tests, integration tests, end-to-end tests, and manual tests. But there are other types of tests, like contract tests, load tests, smoke tests, and what we’ll be looking at in this article—property-based tests. What’s the Idea? Property-based testing is where you test

I’ve written multiple posts about legacy code and automated tests. I believed both are closely connected in that one can help solve the other. I also enjoy working on legacy code, improving software development practices and improving code quality. But this blog has always been geared towards developers, and it seems managers don’t always follow. Which is why I’ve started a new blog, aimed at managers dealing with legacy code. Over time, I’ve come to like improving the situation around

As an independent consultant, I work for companies large and small. But I (lightly) engage in some open source work, from submitting bugs over creating pull requests to maintaining my own RedStar.Amounts library. The open source community has some best practices that are often missing in companies. Here are some that I recommend you try to introduce in your organization. There is a minor disclaimer though: this is not true for all open source work. But most well-maintained open source

This post was written for the NCrunch blog. You can find the original here. Test-driven development is a technique to drive the development of your project. TDD enables you to verify your code, it provides confidence for refactoring, and it enables a cleaner architecture. But what if you already have an existing codebase that wasn’t developed with TDD? How can you get started with TDD in such a (legacy) project? There are several approaches to this, so let’s dive in! The Situation

This post was written for the NCrunch blog. You can find the original here. When you dive into automated testing and test-driven development, it won’t take long before you learn about the testing pyramid. If you’ve never heard of it, don’t worry. I’ll explain what it is first, then go into some variants, and finally explain how you should use it as a guide toward a quality test suite. What Is the Testing Pyramid? Mike Cohn first came up with

This post was written for the NCrunch blog. You can find the original here. In 2018, just about every developer has at least heard of test-driven development. But that doesn’t mean every team is doing it or that every project has an extensive suite of tests. It doesn’t even mean everyone likes it or believes in it. Join me as I start out with some basic facts that no one should be able to deny. From there, I’ll work towards

This post was written for the NCrunch blog. You can find the original here. I once worked at a client site where the technical lead told me not to waste time writing tests. Speed was important and writing tests was a waste of time. Besides the fact that that’s a fallacy (I write code better and faster when I include tests), it also implied I needed his permission to write tests. And it wasn’t a good time for writing tests.

This post was written for the NCrunch blog. You can find the original here. When you first start writing unit tests, all is well and the few tests run in a matter of seconds. After having written hundreds or thousands of tests, running them might take…long. Too long. But when is long too long? How long should your unit tests take to run? And how can we reduce the time it takes, without removing or skipping tests? Why Do We

I’ve sung the praise of TDD/automated testing many times before, but recently encountered an angle I hadn’t considered yet: the importance of automated tests for onboarding. Automated tests have several benefits: if you’re practicing TDD, it generally drives your design in a good direction it provides a safety net for refactoring it can catch bugs it speeds up development it provides some documentation for your code But here’s another advantage: it helps new developers tremendously. In part, because of the

At one of my previous customers, a developer once asked me what I do when a client chooses the quick & dirty solution after being confronted with different options. The story behind it was that some members of the team were frustrated with the technical choices their immediate managers were making. When asked for an analysis of a feature, they would propose a solution that involved clean code, modern standards, tests, etc. In short, the ideal solution. But they would