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.
Write a test
Make it run
Change the code to make it right i.e. Refactor
Adding new functionalities becomes easier
Faster in the long run
Forces you to focus on one thing
Faulty test code/No Silver Bullet
All members should do it
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
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 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.
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.
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.
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.
To make things clear and Flutter-specific, we are using Reso Coder’s Flutter Clean Architecture Proposal. It consists of three layers :
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.
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.
This layer contains UI and state management approaches.
In this post, you learn a little bit about test-driven development and clean architecture. For more, head on to part II.