Automated application testing – A new recruits perspective

Having recently re-joined the ranks of the Nomensa tech team I discovered some advantages to working with an established, fully tested codebase that I had not realised before.  

The majority of benefits associated with testing application code will already be clear to technical professionals working in the industry.  If you are not familiar with unit testing, some of the primary benefits include:

  • Safeguarding your codebase against regressions as the application matures over time;
  • Consistent, reusable tests reducing the potential for human error if checks were performed by a human instead;
  • Tests are reusable eliminating the possibility that specific tests are forgotten or purposefully ignored.

During my professional career I have worked for companies who test their application code, and for companies who do not.  In instances where the companies did not test their application code I regularly put forward the case for starting to do so.  

However, it was only recently that I started to consider how a fully tested codebase aids new recruits with their integration into an established technical team, and the impact this has on the business in general.  This post attempts to highlight the (often overlooked) benefits unit tests offer to new recruits or people ‘getting up to speed’ on a new project.


Developers don’t like to be interrupted.  According to Swizec Teller:

"Working on large abstract systems involves fitting the whole thing into your mind – somebody once likened this to constructing a house out of expensive crystal glass and as soon as someone distracts you, it all comes barrelling down and shatters into a thousand pieces”

In practice, it’s not always possible or practical to join a team and hit the ground running without asking questions.  A certain amount of questions are inevitable, even necessary.  However, the potential impact these questions can have on the wider team and their working day should not be underestimated.  With unnecessary disruptions kept to a minimum your team will feel less stress, save time and ultimately be happier and more productive day-to-day.  

Speaking of my own introduction to the Nomensa tech team, working with well tested application code has enabled me to start working productively without excessive disruption to the wider team.  I attribute this to the fact that the application code I work with day to day is well documented and thoroughly tested.

Declarative tests define how an application should behave

Over the past 12 months there have been a number of times when I have not been 100% sure of the intended purpose of a given piece of code that I have needed to use.  Without a unit test to refer to I would normally have been forced to ask one of my colleagues.  Since I have been working with well tested application code I have been able to refer to the unit tests directly.  In this sense the unit tests themselves have assisted me in understanding the purpose and function of existing pieces of code – almost like a super geeky functional specification.  

By looking at a test rather than code I can determine what a given piece of code is supposed to do (as opposed to relying on what the code does currently). If the application in question had not been tested, the chances are many more questions would need to have been asked and the impact I would have had on the team’s productivity would have been more pronounced.  

Testing your application code not only makes it easier to manage an application as it evolves, but also make it significantly easier to hand a project from one developer to another.


Accountability is a significant issue for untested application code.  I’m not talking about pointing fingers at your colleagues, but understanding how and when an issue might have been introduced and what the code was supposed to have done in the first place.  

With an untested codebase there is a greater change that developers will attempt to work around long standing bugs in the system with ‘quick and dirty hacks’.  It is easy to see why this can happen without tests, as they might not understand why code was there to start with.  

Fixing a bug in an untested codebase can trigger bugs in seemingly unrelated ‘workarounds’ elsewhere in the code.  Without tests in place these regressions can mount up, often getting noticed weeks, months or years after the bug was made live.  

In these situations developers will often need to spend time digging through the application code in an effort to identify the codes purpose and consequently fix any issues identified.  The amount of time needed to fix these sorts of issues can be significantly increased according to:

  • How far the codebase has evolved from the original implementation;
  • How many people have worked on the codebase during its lifespan;
  • How long any given issue has been present in the codebase.

When I work on any new feature I ensure that my tests are updated accordingly.  Once I am happy that my code is ready for release and that all tests are appropriate and passing, I can commit my changes back to the code repository, confident that the next developer to work on the project will be alerted to any regressions they may introduce.  

At this point I can forget about the work I have completed and dedicate myself to thinking about the next task in hand.  I can do this by virtue of the fact that the code I have committed safeguards against any potential regressions introduced by another developer at a later date.  This not only allows me to focus on the task in hand but makes it easier for other developers to pick up from where I left off.

Confidence in the quality of the codebase

When working on an existing application with good test coverage I can be confident that it is fully functional when I start working on it.  If tests fail when I first check some code out of our repository, I can easily track down the broken code and speak to the relevant people to get it fixed.  If I inadvertently cause tests to fail as a result of an update I have made, it should be immediately apparent what has broken and why.  In these situations I would fix the regressions I have introduced before releasing my code.  

Knowing that I have a suite of tests for any given application I work on affords me more confidence to change existing code.  Knowing that any regressions I inadvertently introduce into an application will be flagged up by the tests gives me a valuable safety-net that can be (to a greater or lesser extent) relied upon to catch bugs before they are rolled out to a production system.  This means that I am far more likely to dive into code without asking unnecessary questions of my colleagues, and hence, has a very real impact on the wider team.


We all know that testing application code is a good thing.  However, I hope that this article has highlighted some of the, often forgotten, benefits unit tests have for your team and business in general.

Speaking specifically of my experience I feel that well tested application code has helped me to:

  • Hit the ground running;
  • Ask fewer unnecessary questions of my colleagues;
  • Understand what I am accountable for in my day to day work with Nomensa;
  • Feel like a valued, valuable member of the technical team with minimal disruption to my colleagues.

If you are considering whether to start testing your application code the only advice I can give is to do it.  It is true that maintaining unit tests can add time to your development lifecycle.  However, this extra time spent during development will be repaid over and over as your application matures.

While it is true that tested applications save businesses time and money, the most noticeable impact for me has been the ability to integrate with the tech team here at Nomensa with minimal fuss.

Add a comment

Fields marked with an asterisk (*) are mandatory.