How to not be annoyed by tests and why they are important — Part 1

Some developers simply seem to be annoyed writing tests

Developers tend to not write tests, the code is really hard to test or we simply don’t have time to write tests. For the last 3 years I was always struggling to test our software.

These are merely excuses about not writing tests at all. If you are writing software which is generating money in one way or another testing is not an option — its a necessity.

In this two part article I will set some spotlights on the why its important, how to automate and when to run. First part will be about the why its important.

Why is software unit testing important?

Lets do some cooking

First product to be tested ©flickr.com

Cooking? You serious?

Yes I am. Cooking is pretty much a good analogy to unit testing.

Lets start off by making an omelette. What ingredients do we need? Well not that much, but could be something like:

• Eggs
• Milk
• Bacon
• Cheese
• Salt
• and more

Next thing we (hopefully) do is to inspect, evaluate and verify our ingredients if they suit our needs.

• How many eggs do we need?
• What kind of milk? Spoiled? Bio?
• Frying pan heated enough?
• Is it really salt or is it sugar?
• And so on…

As you probably noticed, we are testing our ingredients or units. As we are in the process of creating our product, we do test our work and each component throughout.

But we’re not testing the whole product.

In some cases one may simply take each component and make the product, without looking at the conditions of them. You will get the same product in the end but there are implications:

• When finished you can’t change a component
• Too much milk used? To bad, omelette is floating in water
• Used sugar instead of salt? Yummy sweet omelette
• Milk was overdue but you didn’t notice? Maybe you won’t taste it right away but it could have consequences later on

So why is unit testing important? We do it to ensure every part of our product works as defined while developing it. This way problems will be detected before we ship our product.

Unit testing is only one kind of tests we can do, there are many more. A good overview of choosing the right testing tool for your needs is given by Sebastian Bergmann and Ciaran McNulty¹

Embracing the Test Pyramid⁵

Developed by Mike Cohn, the test pyramid is a concept about the amount of tests, where you should have more low-level unit tests than high level end-to-end tests running through a GUI.

There is also a relation between speed and cost of money in the same way. Unit tests are per definition faster than end-to-end tests using a GUI. Going up in the pyramid the cost of maintenance will increase significantly.

“Writing tests takes so much time”

A sentence I hear most of the time if I do ask developers to write some tests for their implementations. But does is it really take so much time?

Well you could argue that if you skip the tests, your feature will be shipped faster. Could be true. But what about the time you’re spending on fixing bugs that occur on the customers side? Your customers won’t be happy and this is also time going into development for this particular feature and it will be much harder to find the problem and make sure it never happens again.

If you write your tests before-hand, like with test driven development (TDD), you could have seen these problems right away and have shipped a feature which doesn’t break on the first click.

Unit testing is a lot like going to the gym — Benjamin Ragheb²

One might say: “I don’t know how to write those tests. Do I even need them?” Well skill comes with practice. It is a lot like going to the gym. You know it’s basically good for you, but you tend to avoid the work.

The more you do it, the more you’ll like it — Sebastian Bergman, Jeffrey A. "jam" McGuire³

The more you do TDD the more you will like it. You will get used to it and even speed up your development process by doing so. Another benefit? Your code quality will increase as well — your coworkers and your future self will thank you.

Running all those tests takes too much time

Every time you change something you should run your tests. Maybe you just broke something without even knowing it. But what if running these tests take too much time so you have to wait to see if you broke something?

If you are working on a project with a lot of tests and they take a lot of time, you should first be thankful that you have tests. On second thoughts, maybe some tests are running in the wrong context? For example running integration (third-party component) tests all the time might be slow, so only run them when you really need it. For example when you deploy your feature on some kind of testing environment or doing continuous integration.

The 10 second rule

Unit tests should be written in a way, that they don’t consume too much time and can be run behind the scenes all the time. There is a simple rule of thumb that unit tests should not exceed a 10 second mark, published by Mark Seeman⁶.

He points out that our mind will lose focus if we have to wait more than 10 seconds for our tests to finish. This should be applied to the whole test suite. The more tests you have, the faster they have to complete.

But this could limit your ability to provide more an more tests if you can’t get them to execute faster? No. Then you would simply run a subset of these tests for the code you just changed. The full suite should be run on your CI server.

The broken window⁴

On my work I always had the problem with running our tests. Those tests took ages to finish, so we simply skipped them because it was annoying to wait for them to complete. What happened afterwards? Test didn’t get executed at all and we changed so much that most of the tests simply broke and stopped working at all.

This should never happen!

Think of the theory of the broken window. If one test fails and no one is fixing it, soon more tests will fail and no one will take care of it until it totally breaks down.

Next up: How to automate your unit tests

In the next part we will look into how to automate your unit tests with PHPStorm and Vagrant so you don’t have to bother with them and can do what you want to do — coding.

[1] https://thephp.cc/dates/2016/05/php-serbia-conference/finding-the-right-testing-tool-for-the-job
[2] https://stackoverflow.com/a/69263
[3] https://thephp.cc/dates/2016/10/international-php-conference/testing-the-more-you-do-it-the-more-you-will-like-it
[4] https://en.wikipedia.org/wiki/Broken_windows_theory
[5] https://martinfowler.com/bliki/TestPyramid.html
[6] http://blog.ploeh.dk/2012/05/24/TDDtestsuitesshouldrunin10secondsorless/