Why We Do Unit Testing

At New Media Labs we strive to be awesome. We want to deliver great solutions to our clients and have fun doing so.

In the dynamic software development industry you need to experiment, adapt and find out how to be super-efficient without sacrificing quality. It’s a challenge.

In this series of blog posts I will describe in detail the things we do and why those things work so well.

Problem Nr1: Broken Code

Any reasonably sized software application (or website) is essentially a complicated machine composed of inter-related components. A large part of a software engineer’s job is to simplify that complexity by compartmentalizing  parts of the system and writing code that does what it’s supposed to but is also understandable . After all – how can someone maintain your code if they struggle to figure out what it does?

Yet, despite all our best efforts Errors still creep into the application. For example: I may innocently make a small change to how a financial calculation is done, and unwittingly break several other web pages that I did not realize would be influenced by my change. And the breakage may only be noticed several days later, making it very difficult to try and determine why the pages broke.

Unfortunately this is just the nature of software development: “Bugs Happen”.

Wouldn’t it be great if there was a way to protect against breaking code? And to detect bugs as soon as possible?

Problem Nr2: Being afraid to change code

The world is moving at a rapid pace. Businesses change and need to adapt to be able to take advantage of gaps in the market.

Nobody understands this better than a software developer who has had to change how a system worked even before they were done implementing it completely first time ’round.

Unfortunately changing code can be scary, because your change may break existing features without you realizing it. So often developers try to make changes in a way that is unlikely to break something else by “sticking” the code on the side of the system where it interacts with as little other code as possible. This obviously results in a poorly integrated solution that is difficult to maintain. It results in bad code.

Wouldn’t it be great if existing code were easy to change? That developers could respond rapidly to business demands and fearlessly change the entire solution to better fit the business requirements?

The Solution: Unit Tests

We believe Automated Unit Tests help alleviate the problems mentioned above. Automated Unit Tests promote developer confidence and helps protect against bugs.

When we code a new feature, we write two types of code:

1. Feature Code: Code that is the feature requested by our customer.
2. Automated Test Code: Code that tests the Feature code.

A single website that we  build will be covered by hundreds of unit tests. We run these tests several times a day while we are busy extending or modifying the client’s code. We use a test runner developed by JetBrains. Its output looks as follows:

Have a look at the output of the test run above:

• For the client project we ran 534 tests. It took less than a minute to run all the tests.
• Tests are nested underneath each other. Different sets of tests test different parts of the system.
• 1 test failed and the message at the bottom describes why. When a problem like this is detected it has to be fixed immediately.

The important thing to note here is that we always run all the unit tests, as opposed to only testing the small part of the system that the programmer is busy changing. This means that the entire system is tested several times a day for defects.

What we test

A software solution is made up of layers where top layers depend on bottom layers. For example (this is simplified):

• The User Interface layer displays web pages to the user. It relies on…
• The Business Logic layer that knows about business entities and how they behave. It relies on…
• The Data Access layer that knows how to interact with a database to save and load data.

One way to test would be to test the User Interface Layer and let it interact with the layers below it.

We do not test this way. Testing all the layers together leads to slow tests that are brittle and hard to configure. It also means that the causes of failures are difficult to track down because the bug could be anywhere in numerous layers.

We prefer to test layers and individual components in isolation. We do this by supplying fake implementations of the layers on which the code depends. For example:

Testing layers individually means our tests execute quickly and errors are very easy to pinpoint. We prefer writing lots of little tests as opposed to a few big ones.

A single “Business Logic” test may do the following things:

1. Configure “Fake Data Access” to return certain data when called – For example: return a fake Person when called.
2. Call a “Business Logic” operation – For example: calculate investment income for a Person.
3. Check result of the operation – was a calculation done correctly?
   3a.  Flag the test as “Failed” if the calculation did not yield the expected result.

Conclusion

We believe in writing unit tests because:

• Unit tests are much faster than manual testing. The entire system can be tested several times a day.  (although we obviously still do lots of manual testing to pick up issues that unit tests can’t detect)
• Unit tests give developers confidence to make changes and keep the system clean and easy to maintain.
• Unit tests save time (it’s very time consuming to find and fix broken features once the code has gone “Live”).
• Unit tests make everyone sleep better at night.