TDD in Flutter Part 1: Introduction to Test Driven Development

In this series I am going to explain how you can apply principles of the Test Driven Development (TDD for short) to a Flutter (or Dart) project.

This first part will be dedicated to the basics of TDD and trying to understand when it is relevant to use it.

What is TDD ?

You know what they say, a picture is worth a thousand words so here is a representation of the Test Driven Development cycle :

But what does it means concretely ? Well if we consider a newly created project before even starting coding anything you should be able to write a test that fails and then write the code needed for the test to pass, then you can refactor the code if needed and repeat the cycle again by writing another test.

Of course it is not always relevant to test everything in your application especially while developing in Flutter, you will rarelly need to test your entire UI and ensure that each of your AppBar are correctly displayed for example. But it might be interesting to unit test some API calls if your application is consuming data from an external service or make database related test if your app relies a lot on it. In the end TDD will hugely improve the stability and quality of your code especially if you are maintaining or contributing some open-source code. By doing so you will accomplish two things:

1. You will be avoiding regression in your code or code writen by somebody else. If you decide to make some refacto to your code, add a behavior to it, or some service you were relying on changes, you will be able to immediatly see which part of the project doesn’t work as before.
2. It will be easier for your code to respect the Interface segregation principle and the Dependency inversion principle described in the SOLID architecture. Because to make your code testable you will need to separate your interface and abstract part of your code. (Thanks “Uncle Bob”)

The first test you will see in Flutter

You might already know it but when you create a new Flutter project there is a test file generated in the test/ folder of your project for the base counter application.

The code is clear enough by itself, basically it will simulate your widget rendering and actions, its purpose is to simulate some user input and it will expect to contains some specific text widget.

It is called widget testing, the goal is to verify if a widget has the expected behavior. While it is also important to test your UI it is not always the easiest kind of test to write. In a future article we’ll see how to test your UI by using widgets snapshots comparison with the golden_toolkit package.

In Flutter you will find three categories of automated test:

1. Unit test: tests a single function, method or class.
2. Widget test: tests a single widget.
3. Integration test: tests a complete app or large part of an app.

For now you might want to give a try to the unit tests, in my opinion they might be the easiest to write at the beginning. If you don’t know where to start don’t worry we will see how to write a unit test in the second part of this series.

If you cannot wait the next article you can already check the introduction to unit testing from the official Flutter documentation.

Conclusion

Thank you for reading this article I tried to stay simple in my explanations. In the next part I’ll explain how you can write a unit test, while I do not have a full roadmap I am planning to explain in the future how you can mock your dependencies and test your widget with snapshots comparison. If there is some specific subjects you would like to see in the next releases you can leave a comment.

And of course if you liked this article and want to show your support for this series you can clap it (up to 10 times) and/or leave a comment. Also if you are interested in the next part do not hesitate to follow me so you will be notified.