{"id":471,"date":"2016-02-07T18:24:58","date_gmt":"2016-02-07T17:24:58","guid":{"rendered":"http:\/\/joost.vunderink.net\/blog\/?p=471"},"modified":"2016-02-21T21:11:31","modified_gmt":"2016-02-21T20:11:31","slug":"automated-software-testing-part-1-why-should-you-test","status":"publish","type":"post","link":"https:\/\/joost.vunderink.net\/blog\/2016\/02\/07\/automated-software-testing-part-1-why-should-you-test\/","title":{"rendered":"Automated software testing part 1: why should you test?"},"content":{"rendered":"

Next: part 2<\/a><\/p>\n

This is the first post in a series about automated testing of software.<\/p>\n

A long time ago, before I started my professional software development career, I had no experience with unit testing, or any type of automated testing. When I wrote a piece of code, I ran it manually with different inputs to verify that it worked. The blessings of a physics education, where many scientists were just fiddling around with code!<\/p>\n

I’m sure many people did it like that back then, and many people still do nowadays.<\/p>\n

Then, at my first job, one of my colleagues insisted that I wrote unit tests for my code<\/a>. At first, I didn’t see much use of it, but because he was the senior guy and I was the newbie, I did what he said.<\/p>\n

That was a massive step forward in my software development skills. Over the years, I gained more experience, and my respect for automated testing kept growing.<\/p>\n

There are also other types of testing, for example\u00a0component testing<\/a>, UI testing<\/a>, and integration testing<\/a>. This series will look at\u00a0these different types, hence the more generic name of automated testing<\/em>.<\/p>\n

In this series, I want to share with you the fine points of automated testing.There are many introductory posts to be found, where a function to multiply 2 numbers is defined and then unit tested. This series will go much further than that. It\u00a0will be an advanced series, where you will learn how to write tests for a large system properly.<\/p>\n

But first, let me try to whet your appetite by listing some advantages of automated testing. I have experienced all these advantages first hand.<\/p>\n

You will find more bugs earlier.<\/strong><\/p>\n

This is a no-brainer of course. When you write tests for your code, you will find bugs. And you will find them early – long\u00a0before your code is deployed.<\/p>\n

You will prevent\u00a0fixed\u00a0bugs from reappearing.<\/strong><\/p>\n

When you fix a bug, it is good practice to create a test that demonstrates that the bug has been fixed. If you have such a test, and you modify your code later on, you can be confident that this bug will not reappear.<\/p>\n

You will prevent bugs in part A when you modify part B.<\/strong><\/p>\n

This is a common, and very frustrating, occurrence. You change a part of your code, and somehow a different part of your code breaks. If you have unit tests for the other part, you will be able to detect the breakage while you are coding – and fix it immediately. This is called regression testing<\/a>.<\/p>\n

You will protect yourself against silly mistakes.<\/strong><\/p>\n

Sometimes your code looks good. And it compiles. And the server\u00a0starts up. But you made a typo somewhere, maybe a +<\/span>\u00a0 instead of a –<\/span>\u00a0, or 8640 seconds in a day instead of 86400. Or you forgot to include a necessary module. Having a test will find these issues before they become problems.<\/p>\n

You can demonstrate\u00a0how the code is meant to be used.<\/strong><\/p>\n

Tests can be great complements to documentation: they show how your code is meant to be used. I usually\u00a0start by looking at the tests, when learning new modules or projects. They are often\u00a0better at showing how the code works than the documentation.<\/p>\n

You will refactor your code.<\/strong><\/p>\n

Often, when you are writing tests for a function, you conclude that it’s going to be a lot of work and\/or difficult to test this function. The logical solution is to refactor such a function into smaller parts, to make each part easier to test.<\/p>\n

It’s not always about function size, but about having a function that does too much. For example, a function that reads a file, parses the content, and sends an email will be hard to test. Split it into 3 parts, and testing will be much easier. The resulting code will be better as well.<\/p>\n

Your design will improve.<\/strong><\/p>\n

This is an extension of the previous point. Sometimes you get new insights during refactoring, which leads you to improve your overall architecture.<\/p>\n

You will deploy broken code less often.<\/strong><\/p>\n

The more tests you have, the less the risk that you deploy code that doesn’t work correctly. It is of course not a guarantee of faultless deployment, but it will certainly improve the odds.<\/p>\n

You will have more confidence in your code.<\/strong><\/p>\n

This is the vaguest advantage, but for me personally a very strong one. When I’m working on code that has proper automated testing, it just feels better<\/em>. I am more confident about making changes or expanding the code. I work faster because I’m less scared of breaking something important.<\/p>\n

 <\/p>\n

These are the reasons why almost all of the code I work on, has automated tests in some form. Both my professional\u00a0and my personal<\/a>\u00a0code<\/a>. There are some exceptions, like one-time scripts and throw-away proof of concept code (does that actually exist<\/a>?). I hope this list of advantages will nudge you to writing more unit tests.<\/p>\n","protected":false},"excerpt":{"rendered":"

Next: part 2 This is the first post in a series about automated testing of software. A long time ago, before I started my professional software development career, I had no experience with unit testing, or any type of automated … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[272],"tags":[],"class_list":["post-471","post","type-post","status-publish","format-standard","hentry","category-testing-software-development"],"_links":{"self":[{"href":"https:\/\/joost.vunderink.net\/blog\/wp-json\/wp\/v2\/posts\/471"}],"collection":[{"href":"https:\/\/joost.vunderink.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/joost.vunderink.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/joost.vunderink.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/joost.vunderink.net\/blog\/wp-json\/wp\/v2\/comments?post=471"}],"version-history":[{"count":8,"href":"https:\/\/joost.vunderink.net\/blog\/wp-json\/wp\/v2\/posts\/471\/revisions"}],"predecessor-version":[{"id":497,"href":"https:\/\/joost.vunderink.net\/blog\/wp-json\/wp\/v2\/posts\/471\/revisions\/497"}],"wp:attachment":[{"href":"https:\/\/joost.vunderink.net\/blog\/wp-json\/wp\/v2\/media?parent=471"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/joost.vunderink.net\/blog\/wp-json\/wp\/v2\/categories?post=471"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/joost.vunderink.net\/blog\/wp-json\/wp\/v2\/tags?post=471"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}