What is Test-Driven Development And Why You Need It

If you’re going to put time and money into your app, you need to ask about test-driven development.

You may have heard about manual testing, where a dedicated staff clicks through an app to check for errors and functionality. Unit testing is when individual components of your app are being tested — and Test-Driven development is a development approach based on unit tests. Testing in software development is all about ensuring that all your apps features are functioning properly.

Without TDD the testing process is usually:

1. Write a bunch of code.
2. Run the app and see if it “works”.
3. Repeat 1–2 times until it works.
4. Sometimes there are additional steps, like handing over the app to the client or a Q&A team who check it for themselves.

With TDD, the process looks quite different, because developers are focusing on small chunks of features. For example, if you want a button to log a user in — the 1st assumption is that you need to have the correct title for that “Log In” button. The developer will then:

1. Write a code that checks whether the button has the “Log in” title.
2. Run the “app” to check whether all of your assumptions are valid — it should be invalid (red phase).
3. Write a code that actually sets this title.
4. Run the “app” that checks whether all of your assumptions are valid — it should be valid (green phase).
5. Modify the code for readability.

These assumptions are written one by one. And when a developer thinks they are finished, they will run the app and see how it pans out altogether. If necessary, they will add more assumptions.

Simply put…instead of running the app to see that each small change worked every time, TDD is about writing a piece of code that checks it first, so by the time the developer has it implemented, they can auto-check if this set of features works.

Why do I need TDD in my app?

Test Driven Development (TDD) is a method of creating digital products in a way that greatly reduces the risk of your app crashing. If you’re going to put time and money into have your great business idea developed into an application, it only makes sense that you would want this app to not only be usable but also as flawless as possible, to keep your users coming back for more.

We’ve all been there…when we find an app that seems to fit exactly what we’ve been looking for, but it crashes when trying to do a simple task — chances are we just move on to another app that is offering a similar service, but lets us complete the task.

TDD can increase the success of your app, because it also allows for your project to be worked on by multiple developers (hand-offs with TDD are much simpler), and it also saves time when trying to improve features or add new ones — ensuring that these features work and function as you imagined they should. For successful and long-term business ventures, these 2 factors are incredibly important.

Let’s look at how tests work, when to use them, and some case studies.

How Tests Work

A test is just another piece of code that automates what a developer does manually. It runs the app to check whether any changes introduced, messed up previous code or logic or if everything is still working.

Normally, the logic of tests is that ‘If I do A, I expect output B.’ Tests are usually used during the development process. Often clients are offered the repository of code for the working application and the tests ‘on the side’.

Using test-driven development in your projects improves the quality of your code, which in turn improves the quality of your product.

When should TDD be used?

Always. Developing using TDD improves the quality of code in your product, and will greatly impact the usability of your product for the end-user.

Ideally, tests are written before the code is. Writing the tests allows mobile developers to understand what’s already in the code. This also ensures that developers are writing clean code and allows them to determine what is really necessary, in order to avoid overcomplicating things. This is called test-driven development (TDD).

You can’t really start adding unit tests to a code base that wasn’t written using TDD. To write a test for a new piece of code, you have to adapt things in the existing code. But once you change things in the existing code, you don’t know if you’re breaking something previously written.

TDD is about:

1. correctness,
2. code design,
3. avoiding unnecessary code.

Once all the tests are written, developers then look at the code and try to optimize the human readability performance. These tests ensure that it’s clear if something in the app has been messed up because of changes made.

At a certain point in development, it can become very difficult to add new features, if you don’t have tests. In the beginning, this isn’t really a big concern, but as you proceed in adding features the difficulty of coding increases exponentially. It’s really easy to introduce changes that can break previously written code.

What is Code Coverage?

Code coverage determines how much of the code, for your mobile product, is processed or ‘called’ during tests. Code coverage should mean a higher quality of code and high test coverage should be the assurance that there are no bugs — although it’s not completely foolproof.

Mobile developers should be aiming for at least 85% test coverage, although 100% would be best.

Examples of digital products our iOS team at EL Passion developed.

Use case #1: Benefited from having TDD

Concept & Challenges

This particular example is from a project that we developed, which perfectly demonstrates the value of TDD. It’s especially valuable when a project requires such specific work on the backend side of things. The project cost and timeline both benefited from using test-driven development, and as a result, we were able to successfully deliver a great app.

Imagine there is a system for each post office and the goal is to build an app that requires a backend to unify all of those systems together. This backend would need to ‘talk’ to each post office separately and then combined that data and sends it to the mobile app.

Assume that every system for every post office knows that there is a parcel at a specific office. The mobile app would take the parcel identifier (tracking number) and look up the parcel’s availability for pickup in all of the offices nearby.

Developing the backend for the integrations of separate systems can be pretty challenging. Developers cannot directly work with the separate systems, otherwise, they could corrupt existing data if they’re not careful.

Part of the problem here was that the developers didn’t know what data they were expecting to receive.

When TDD came in handy

In many cases, this could delay mobile app developers, because they didn’t have the data in time to create the feature to go with it, in the app. Normally, it isn’t easy to create new features when there is no data to code. But with unit tests and TDD, there was absolutely no problem.

Developers could normally work on features even if the other part wasn’t completed, which means they were able to deliver new features even though there wasn’t a way to run the app as a result of a lack of data.

Use Case #2: Would have benefitted from TDD

Concept & Challenges

The developers were working for a client as a team extension. In this particular application, when a user was creating an account, the app would reuse the user profile screen for the onboarding process and that’s where the user would input the data. Some very basic features needed to be added to the screen, which in most cases should only take a couple of hours…

There was a team member on the client’s side, who we will call ‘Bob’, who worked on the user profile screen. With no tests involved whatsoever, Bob was constantly adding new features to this screen. Each time he added a new feature, it would break all the code that our developer (we’ll call him Mark) was delivering for the onboarding flow.

When new features were delivered by the Mark, in onboarding, they worked and were approved by the Q&A team. But as a result of Bob implementing his own features, the actual process of development was being prolonged because the changes he was making broke the existing code in the onboarding flow.

When TDD would have been useful

This went on for days or weeks and ended up being very costly for the client, because every change Bob made, meant that he broke some other part of the code. Which meant that Mark had to go back in and find the specific part that was broken, to fix it.

This was time-costly for the client, but also inefficient for our developing team. If this project had used TDD for their development, they could have avoided wasting the additional time and money that it cost them to have developers going in and fixing these small errors that kept arising.

Why is TDD worth it? A Financial and strategic aspect.

There are some concerns for new businesses when deciding how to go about developing their digital products. Some of the major concerns are about time, money and quality of the final product.

When developing your mobile app with TDD, the time extension, depending on the project, can range from 15% to 35% and the issue density reduction can range from 40% to 90%. As an example, MSN reduced issues by 90% for as little as 20% more time added. In this case, you aren’t really paying more, as much as you are developing a much better product — and having the best product is a sure way to set yourself up for success.

Imagine spending the time and money to have an app developed, only for it to crash, and shut down. When you run the app 10 times (10 sessions) with 90% crash-free rate it means the app crashes 10% of the time (1 out of 10).

When you run the app 150 000 times (as in the aforementioned stat) with a 90% crash-free rate it means the app has still crashed 15 000 times, which is outrageous! The crash free rate should aim towards 99.99999999…% or 100%. In a case where an app crashes so frequently, you will likely lose that user-base because your app doesn’t function as your company guarantees.

Skipping over getting your app developed with TDD might be 35% faster, but it’s paying for the product that is flawed instead of really getting what you really wanted.

When we look at the case studies above, we can see instances when TDD was crucial in the success of a project, but can also see how without it, it can actually become more costly. Especially if you are hoping for longevity, in terms of the digital product you create and your business solution. There is a good chance that the original developer who created the project will not be the only person to ever work on it.

For your own piece of mind, using TDD speeds up the onboarding process of new developers to your project, but also ensures that there is working documentation of what each set of code does in your app. Without testing in your code, you are limiting yourself to one developer, or setting yourself up for a timely and costly handover at some point in your apps lifetime.