Test and Quality

On this page, I have collected all the articles I’ve written on testing software.

Reasons to code the tests

Test enables change!

Having a test suite makes the code easier to change. Whenever we do a change, we know that we didn’t break anything. Without the tests we fumble in the dark and have to rely on manual testing, which never will be as exhaustive and complete.

Just the act of writing or changing a test makes you look an extra time on the code, and you do it with another intent than just the happy path. This has helped me discover many bugs before I even check in the code the first time.

It’s boring to test!

Testing your code is boring. It’s repetitive and that makes us do mistakes. It takes time, and that makes us wait until it’s too late. It’s hard to get a complete and repeatable test suite by just doing it. We need to write down test instructions to remember to do the same tests every time. And nobody enjoys that.

Writing unit tests on the other hand, is a creative process. We are coders, we love to code. And unit tests are code. So, choosing between the two, it is a no brainer to choose unit tests.

Does test improve the architecture of my code?

Writing unit tests forces you to write testable code. That makes it easier to read and understand, it tells you what it does instead of hiding things in gigantic code blocks. But the biggest change is that if code is hard to test, you will not test it enough. And that means you don’t know if it works or not. Your clients will get buggy code.

Test driven development

Test driven development

This is an article about why you should do test driven development (TDD).

Write the test before we write the code will give us a full test suite. It is not possible to write any code without a test, so there will always be a test for all the code. But if we write the tests after the code, chances are that we forget things. There is nothing that enforces full test coverage of the functionality.

Writing the test before the code forces us to think before we code. We have to have a goal. We can’t just sit down and plonk code randomly. This means that we will have solved a lot of problems and bugs before we write the first line.

Having to write code that fulfils a test makes the code testable by default. Testable code is a great architectural choice.

Unit testing

What are negative unit tests, and should I bother with them?

I don’t thing anybody has missed the fact that unit tests increase the quality of the code. But then someone starts talking about negative unit tests. What the heck is that?

A unit test verifies that the functionality in the code works as expected, but don’t forget the other side of the coin. Errors. And negative tests verify that your code doesn’t get stumped when an error occurs. Here are a few things that helps you write them.

How to unit test without testing everything

This article is about how you verify only the behaviour of the function you are writing and not include all the other code that the function calls. To isolate the behaviour from the rest of the application, focusing on doing that right. Keeping it simple, clear and understandable.

Yes, it talks about the Dependency Inversion principle. Or as you might know it, Dependency Injection.

The ins and outs of unit testing a black box

A unit test sees the System Under Test (SUT) as a black box. That means that it doesn’t matter what the code inside the class or function looks like, it only matters how it manipulates the data. And the way you judge that is only by the data that goes in and out of the function. Never ever ever by looking at the code.

This forces us to focus on the behaviour of the code we’re testing. Since we don’t see the code, we only see what it does, that’s what we test. And that is what makes the tests decoupled from the code so we can rewrite it and still know that it works.

How to write a unit test

If you never have written a unit test in your life, this is the place to start.

How do we actually write a unit test? Where do we start? What patterns should we use?

This is some of the questions that this article answers.

How to create a test fixture

A test fixture is used to:
● Make the code less brittle. We isolate the construction from all the tests and only do it in one place, so when we add a new parameter in the future, we only have to change the test code in one place.
● Makes the job of writing tests easier, we write less code because we only call a function that creates the instance, instead of writing the entire construction with all the parameters in every test.
● Make the code DRY (Don’t Repeat Yourself). We only do the construction, the newing up, in one place.

And here I try to show you how to write them.

How to create a test builder

A builder is a class that creates another class for you, using a fluent API.
Person me = new PersonBuilder().WithFirstName(“Peter”).Build();
The test builder is used in unit tests to:
● Make the code less brittle. We isolate the construction of the objects used in the tests, and only do it in one place, so when we add a new parameter in the future, we only have to change the test code in one place.
● Makes the job of writing tests easier, we write less code because we only call a function that creates the instance, instead of writing the entire construction with all the parameters in every test.
● Make the code DRY (Don’t Repeat Yourself). We only do the construction, the newing up, in one place.

Are integration tests really the best way?

Integration tests, the tests that tries to test everything at once. This tend to become complex and hard to maintain. And there never seems to be enough of them. Bugs always slip through. But there might be a way to reduce the need for integration tests to a minimum.

Contract tests.

A normal unit test verifies the functionality within a unit. But we don’t test what happens outside of that, between two units, the way they work together. This is where integration tests normally come into play. But we could instead write tests that only verify that two units work well together, that they fulfil the contract between them. That they send and receive what is expected and nothing else, and that we can handle the situations when they actually do that.