TDD on mobile dev, a matter of timing

When we start the development of a product, there is always a desire to make it as perfect as possible: fulfilling the client’s expectations, offering a good learning opportunity to the developer, and delivering a system with high maintainability and scalability.

As the code base grows, keeping it problem-free becomes a harder challenge. Testing manually each module of the application can take so much time that developers may become unproductive.

To solve this issue, automatic test technologies have evolved a lot.

They… well… run automatically. Tests are an additional set of software that developers write to test its own code and ensure the expected outcome.

If you do a quick research about software testing, you may face some recurrent terms like unit tests, integration tests, TDD (Test Driven Development) and BDD (Behavior Driven Development).

The first two are types of tests while the others are software development processes. Let’s go through these concepts for those who are not familiar with them.

Unit Tests

It is a type of automatic test focused on small units or pieces of software, like a method, subroutine or small snippets of code.

As very specific tests, usually they are simpler, quicker, and don’t take too much time to be written. Another important aspect is that each test must be individual – testing only one thing at a time.

Integration Tests

When creating a big software project, it’s only natural to split it into modules/submodules. These components must be able to communicate with each other, that is, they must be integrated.

To ensure that the integration is working properly, automated tests may be written.

These kinds of tests allow developers to find problems in more complex structures, where a simple unit test may not be enough.

What is Test Driven Development?

TDD is a process where a test is developed to set a definition of done before the actual code implementation.

One important thing to keep in mind is that TDD is built upon unit tests, but doing unit tests is not the same as having development driven by tests.

It consists of three basic steps (Red-Green-Refactor cycle):

1. Write a test that will fail: this should happen because the actual implementation code has not yet been created;
2. Code just the bare minimum to pass the test: this will keep the developer focused and provide clarity on what should be implemented;
3. Refactor the code: improve performance and readability. The new code must not fail the test.

This is why it is called TDD: because the test drives the development, not the other way around. This has a dramatic impact on how the software is crafted.

Behavior Driven Development

BDD means to have tests describing behavior that the user can expect from the system. It emerged from TDD and is an extension of it, in the sense that development is driven by behavioral tests.

It uses natural language constructs (English-like sentences) to express the desired behavior and expected outcomes.

It consists of three sections:

1. Context: the initial state
2. Event: some action that the user performs
3. Outcomes: expected results

Let’s see a brief example to clarify these concepts:

These tests may be written before, during, or after creating the implementation code. When before, they guide the development, leading us to BDD.

Benefits of Tests

Among many of the benefits offered by a good suite of tests, we may cite:

• Quality assurance;
• A clearer and simpler code base;
• Reduces the chances of breaking the application when you add a new feature or make a modification (regression);
• Progress tracking;
• Reduce time spent on fixes;
• Encourages the creation of enhancements on the current code base.

Drawbacks of Tests

If there are so many benefits associated with developing a suite of tests, why are not all developers doing it?

Here are some of the reasons:

• Increase in the development time: as most development companies charge by the hour, the initial project cost will also increase as a consequence;
• Additional complexity: writing tests is not the same as writing good tests, and creating good tests can be really challenging sometimes;
• Many developers are not used to writing tests: it may be intimidating if they have to learn by themselves;
• It’s hard to test legacy code;
• It’s difficult to maintain the test suite if the requirements of the project are not clear and keep changing.

When should you use (or not) tests

Each company and each product are unique, so there is no magic formula to tell you if or when you should be writing tests.

However, there are some points to take into consideration:

Mostly of early-stage startups have a low budget, want to enter the market, have a small dev team, and have no idea what the final product will require.

They want to reach the clients as soon as possible, spending the minimum to validate the product.

This leads to a situation where you should focus on getting the features ready and iterating on them quickly with real users, so spending many resources on tests (to features that might be ruled off soon) might not be the most cost-effective approach.

The initial costs and time of using a TDD or BDD approach are higher, but they usually pay off in the long run. It will reduce both the total time of development and the time wasted with fixes and bug tracking.

On the other hand, there’s a point where the application will grow so large that keeping a no-test approach becomes cumbersome.

When having too many moving parts, even a slight change on the app might crash the system, demanding huge amounts of refactoring.

At this stage, the company usually has more resources, so investing time (and money) in testing becomes the more efficient and profitable approach. Therefore, it is necessary to reevaluate from time to time what stage your business is at.

Wrapping up

Antonio Duarte, the Cheesecake Labs VP of Customer Success, shares his thoughts about when is the right time to start testing your app from a business perspective:

“Ideally you should test everything. But we’re not in an ideal world. When starting a brand new MVP app, tests aren’t the most important layer, since you are still validating if the features that you planned make sense or not. Although tests can become very straightforward for an experienced developer, they still represent part of the development time and cost of the product.

When the launch date comes and the product starts getting public feedbacks, the team will be able to evaluate the right features that potentially need another level of robustness and then be covered with tests, so you won’t expend time testing features that will be soon removed, investing time and budget on new ideas or into other relevant features. In the case where the product is already validated and the company will rebuild it to achieve a better level of performance or redesign, then start testing from the beginning is a smart decision.”

Using TDD, BDD, or even just writing unit tests for your project has many benefits and pays off in the long run.

But one should evaluate the stage of the product: you won’t always have time or money to invest and do everything perfectly, sometimes it is more important just having something done to enter the market and validate your product.

Here at Cheesecake Labs, we do our best to write a good test suite when the right moment comes.