Skip to main content

Why unit testing is still very relevant

In this age of in-memory test servers and databases, multi tenancy-first design, and increased performance it's easy to simply dismiss unit testing as a practice of the past. Whilst I myself have increased my dependance on integration testing in new applications that I write. Unit testing still has its place.
A set of beer-units about to be tested | source: WikiMedia Commons

In 2017, I've gave a few talks about testing more and mocking less. I still stand by this. An excess of mocking actually negates one of the largest advantages of unit testing: understanding dependencies and helping organise code better into single responsibilities. The practice of testing (no matter at what level) is to validate your code-proper, edge cases, replicate issues that have occured in production, and act as a safety net so that code-proper doesn't break into the future.

TDD unit testing in particular has the added advantage of helping organise code into single-responsibility dependencies, smaller methods, and better named classes. Why? because production code is consumed (or called) prior to it being written, meaning that you have to understand the dependencies of your unit-under-test.

Whilst it may be tempting to have an integration test heavy application and completely discard unit testing, especially with new technologies coming through. I would suggest that your testing strategy be seen not only from the prism of code validation only but also code organisation.

Thank you for reading


Popular posts from this blog

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

Context and agile practices

At times we have competing responsibilities - ship code or don't ship it because of a small edge case bug; put pressure on our team or make the business happy; coach our friends or write code.

This is a normal part of our everyday professional lives, and it's important to strike a balance that will help us in the future, but also deliver in the short-term.