Learning TDD with Clean Architecture for Flutter Part I

This will be four-part series in which we will learn about TDD in Flutter.
Part II here
Part III here
Part IV here

TDD(Test Driven Development)

TDD is an approach in which the test is written to validate the code that we write. Here the test is written and the code is modified to pass the test. It is also known as Test First Development.

TDD cycle defines

1. Write a test

2. Make it run

3. Change the code to make it right i.e. Refactor

4. Repeat process

TDD Advantages

1. Documentation

2. Fewer bugs

3. Adding new functionalities becomes easier

4. Faster in the long run

5. Tidier Code

6. Forces you to focus on one thing

7. Clean Interfaces

TDD Disadvantages

1. Slow Process

2. Faulty test code/No Silver Bullet

3. All members should do it

4. Increases Complexity

5. Design dependent

Clean Architecture

Clean Architecture is also known as Domain-Driven Design. The primary idea in Clean Architecture is to make the solution adaptive, and keep the core business or application logic use cases independent of frontend and external frameworks.

It produces the system that is:

• Independent of Frameworks

• Testable

• Independent of UI

• Independent of Database

• Independent of any external agency

In clean architecture, codes are divided into layers. Inner layers are independent of the outer layer and changes can be made to the outer layer without ever touching the inner layer. It follows the **Dependency Rule. This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle. Here it contains four layers:

Entities

Entities encapsulate Enterprise-wide business rules. An entity can be an object with methods, or it can be a set of data structures and functions. It doesn’t matter so long as the entities could be used by many different applications in the enterprise.

Use Cases

The software in this layer contains application-specific business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities and direct those entities to use their enterprise-wide business rules to achieve the goals of the use case.

Interface Adapters

The software in this layer is a set of adapters that convert data from the format most convenient for the use cases and entities to the format most convenient for some external agency such as the Database or the Web.

Frameworks and Drivers

The outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework, etc. Generally, you don’t write much code in this layer other than glue code that communicates to the next circle inwards.

There can be more than four layers. This diagram is only symbolic. There can be more layer as long as it follows dependency rule.

Clean Architecture and Flutter

To make things clear and Flutter-specific, we are using Reso Coder’s Flutter Clean Architecture Proposal. It consists of three layers :

Domain Layer

It is the inner layer that shouldn’t be susceptible to the whims of changing data sources or porting our app to Angular Dart. It will contain only the core business logic (use cases) and business objects (entities). It should be totally independent of every other layer.

Data Layer

The data layer consists of a Repository implementation (the contract comes from the domain layer) and data sources — one is usually for getting remote (API) data and the other for caching that data. A repository is where you decide if you return fresh or cached data when to cache it and so on.

Presentation Layer

This layer contains UI and state management approaches.

Folder Structure

In this post, you learn a little bit about test-driven development and clean architecture. For more, head on to part II.