Blog

Good unit tests help you find errors in your code, and are easy to understand and maintain. Bad unit tests however, destroy the whole purpose of your testing effort. If they take over your test suite, you suddenly don’t understand what’s going on any more. So how can you get rid of these bad unit tests? I’ve broken this down to the following 5 bullet points for you.

ISTQB offers a wide range of standardized education in software quality, and software testing in particular. In other words, you can learn pretty much everything there is to know about testing from them. At least in theory. In practice, you still have to face the reality of software quality and testing in actual software development projects. Here are my top 4 reality checks I had to face as both a C# Test Automation Expert and Test Manager.

With the increasing acceptance of agile software development in practice, testing practices must also be adapted stay suitable for this trend. Reduced release cycles and constantly changing requirements pose huge challenges on current unit testing practices. In this article, you’ll get three smart strategies to cope with these challenges in your daily unit testing.

Whereas software testers are the professionals explaining everyone why it is most crucial to exhaustively test every part of your software, it is often difficult for developers to see the benefit of testing. However, especially when it comes to unit testing, the developer is the one that has to do most of the work – but also receives 10x benefits compared to the effort spent on writing test code. Here are three use cases how unit testing will benefit your work as a software developer.

Agile software development is gaining traction in more and more companies these days. But all coding agility loses its purpose if your software testing practices are not up to speed. The mindshift that still needs to happen here is that in an agile environment, you have to think about testing already while or even before you code. In this article, I’ll show you three easy steps that you can do today as a developer to transform to agile unit testing.

Consistently writing and maintaining your unit tests is a hard and boring task. I will show you three strategies that I use to be more efficient and smart when it comes to unit testing in this article.

Artificial Intelligence (AI) has revolutionized many areas over the last years. However, for the big advantage of fast automation that was not possible before, comes the tradeoff of reduced reliability. In this article, I describe why this is an issue (especially for domains like unit testing), and show a solution how we can integrate humans into an AI-based process to ensure reliability of the created outcomes.

Here are three ways that I use every day to make unit testing easier for me. They’re based and proofed on my experience from writing more than 1.000 test cases as a c# test automation expert.

Although unit testing is a valuable activity for every software development project, it’s also a pain in the ass of every developer who has to deal with it. Why? Because defining, writing, and maintaining your tests over time costs a lot of effort, which you could better spend on writing actual code that creates cool new features in your software. But why is that? Because you are still using ad-hoc ways and inefficient tools to manually write unit test code. In this article, I’ll show you 3 features that you should look out for when chosing a developer-friendly unit testing tool.

Writing good unit tests is a challenging task. There are so many articles available, that try to explain you how to apply good practices and avoid bad ones, that you could spend at least one year of full-time work reading through all of those articles. And after that, you wouldn’t be any wiser, because you still had to apply the 1.000 lessons learned to your daily coding routine.

Running a unit test once helps you find bugs in your code without having to run your software. This can be nice – but the actual value of a unit test lies in running it over and over again – automatically.

Defining your regression tests can be a tedious, and often also difficult task. Which are the unit tests that might detect future bugs in your system? How can you keep the number of regression tests that you have to continuously maintain and execute over the lifespan of your software small, but still achieve a big coverage of your code? In this article, I’ll present you a very satisfying answer to all of these questions: Automation.

Agile software development is gaining traction in more and more companies these days. But all coding agility loses its purpose if your software testing practices are not up to speed. The mindshift that still needs to happen here is that in an agile environment, you have to think about testing already while or even before you code. In this article, I’ll show you three easy steps that you can do today as a developer to transform to agile unit testing.

I’ll show you how easy it can be to keep your test suite in a manageable size – without having to go through the process of defining regression tests.

Let’s do Automated Frontend Tests! This sounds quite easy – but usually turns out to be a real pain in the ass of both testers and project managers.

With all the advances of AI in recent years, people start to phantasize more and more about automating everything, including processes such as unit testing. In this article, I’ll pin down the 2 main arguments why full automation will never actually happen for unit testing.

Regression testing is the key value of unit testing, and the #1 enabler of agile unit testing. A good regression test suite provides you with the confidence that frequent changes did not cause any serious damage to your existing code base. A bad regression test suite however does not provide any value, as it either (i) contains too few tests to actually give some insights into your software quality, or (ii) it contains so many tests that they are not feasible to maintain, meaning that when they fail, the reason is that they most likely are simply outdated. In this article, I’ll show you three easy steps to define your perfect regression test suite.

One key aspect of unit testing is identifying how many unit tests you should have for your project. Keeping too many tests will lead to an increased maintenance effort. Having too little tests will obviously lead to important bugs being missed. So how can you find this sweet spot in the middle, where your test suite brings you maximum value? In the end, judging this effectiveness of your test suite comes down to one single question, which I will break down for you in this article: What is the value of each test case in comparison to its costs? So, how can you answer this question in practice?

Writing unit tests is easy. Most unit tests however do not provide actual value to your software. They don’t actually help you improve software quality, but simply require a lot of effort to create and maintain these tests. Evaluating the actual value that your test suite in practice is usually quite tricky, and requires a whole bunch of experience. To make this easier for you, I’ve broken it down into three questions you can answer in order to identify the value of your test suite.

Value-driven test suites offer a way optimize the maintenance effort by focusing on the test cases that provide most value for you. This means defining those tests that matter most, but also regularly reducing your tests. But how to do this in practice? I’ve pinned down the answer to this question to 3 golden rules of value-driven test suites in this article

In this article, I break down the most essential unit testing pattern for you, and demonstrate how you can apply it in practice.

In this article, I’ll show you the 3 keys to reduce the overall cost of unit testing.

Some guidance on what you have to consider when using tests in your pipeline that deploys code from dev to ops, and the way back from operations to the development of future releases.

In this article, I’ll show you three tools that you can use to find an answer to this question in your project.

In this article, I’ll give you some actionable advice on how to talk to business people, so that they understand why they need to listen to you. Because in the end, the way that business profits most is if you can do your best work!

In this article, I show you two tremendous time savers that you can start using tomorrow to save 60 % of the effort you use for unit testing. Most of our time in unit testing is spent on what I call time monkeys. These time monkeys are tasks that cost a lot of time, without actually creating a lot of output (i.e. code).In the following, I describe the two most prominent time monkeys, and how to overcome them using (i) Equivalence Class Partitioning, and (ii) Boundary Value Analysis.

Unit testing often involves a lot of tedious, repetitive work that takes a lot of your time that could be spent on something more meaningful and fun (like adding actual functionality to your code). So here's a simple rule for writing better test.

Value-driven test suites offer a way optimize the maintenance effort by focusing on the test cases that provide most value for you. This means defining those tests that matter most, but also regularly reducing your tests. So, how do we do it?

Value-driven test suites offer a way optimize the maintenance effort by focusing on the test cases that provide most value for you. This means defining those tests that matter most, but also regularly reducing your tests. So, how to do it?

Value-driven test suites offer a way optimize the maintenance effort by focusing on the test cases that provide most value for you. This means defining those tests that matter most, but also regularly reducing your tests.

Value-driven test suites offer a way optimize the maintenance effort by focusing on the test cases that provide most value for you. This means defining those tests that matter most, but also regularly reducing your tests. So how do we go about it?

Value-driven test suites offer a way optimize the maintenance effort by focusing on the test cases that provide most value for you. This means defining those tests that matter most, but also regularly reducing your tests. How do we do it?