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
Write a test
Make it run
Change the code to make it right i.e. Refactor
Repeat process
TDD Advantages
Documentation
Fewer bugs
Adding new functionalities becomes easier
Faster in the long run
Tidier Code
Forces you to focus on one thing
Clean Interfaces
TDD Disadvantages
Slow Process
Faulty test code/No Silver Bullet
All members should do it
Increases Complexity
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.
Top comments (0)