Meltwater's Anton Hägerstrand Talks Automated Testing at MEST

Last Thursday, MEST Incubator Fellow Anton Hägerstrand held a workshop on Automated Testing. Anton comes to MEST from Meltwater, where he works as a software developer in Stockholm, Sweden. Read on for his top takeaways!

Use both manual and automated testing

All programmers make mistakes. More experienced developers are generally better at mitigating these mistakes. One technique to do this is to use automated tests for your software. Automated tests are cheaper than manual tests.

This does not mean that manual testing is to be avoided. Use manual tests as a complement to automated tests. Manual tests can be used in scenarios where automatic testing is challenging, such as UI testing and integration tests in new code bases.

Use unit testing for complex logic, not for glue

Unit tests are the simplest forms of automated tests. You test a small part of your code (such as a function or class), rather than the entire application. Code that has complex logic, for example sorting or calculations, is well-suited for unit tests.

For code that is more about integrations than logic, one usually has to use a technique named ‘mocking’ when writing unit tests. Mocking involves creating fake objects to replace code that you don’t want in unit tests - e.g. database calls.

In my experience, mocking tends to miss important details since it does not actually test the API. I much prefer integration tests, which test the integrations properly. One technique you can use to do integration tests is to make the tests set up the environment using Docker (or a similar platform). This tends to find way more bugs than unit tests with mocking.

Test-Driven Development

Test Driven Development (TDD) is a way of building software that involves writing tests before you implement any functionality. For a more detailed description, check out this Wikipedia article or the TDD by Example book.

I usually use TDD in the same situations as unit tests - e.g. when the code tries to solve a complex logical problem. One of the nice things is that you will get a set of relevant unit tests that you can keep for regression testing, and I find that the code generally becomes cleaner.

Many people seem to believe that TDD is universally applicable - thus, that anyone not doing TDD is bad at the job, and good code can’t come without TDD. This is not the case, TDD is one tool to get feedback. Kent Beck’s (the author of the book above) views on this are recommended reading.

Property-based testing is the bomb

Property based testing, also known as quickcheck, is probably the most powerful testing technique I know of, and I would have loved if someone convinced me of it 5 years back.

With quickcheck, you provide a means of checking if the output of the program is correct. You then let the testing library generate inputs to your program. Since this is all done automatically, tests for many thousands of different inputs can be run with very little code. Since the tests are truly random in input, edge cases are generally found early.