Journey of TDD: Bottom-up and Top-down Approach
When I work with Test Driven Development, I first create the smallest part or object of the application and then move on to the bigger part. Later on I found this approach called bottom-up approach, but there some other approach than bottom-up which top-down, sound obvious right? Let's find out what is this approach means.
In the top-down approach, an overview of the system is formulated without going into detail for any part of it. Each part of it then refined into more details, defining it in yet more details until the entire specification is detailed enough to validate the model.
In the bottom up approach, individual parts of the system are specified in detail. The parts are linked to form larger components, which are in turn linked until a complete system is formed.
By that’s definitions, this two approach define where we start building the system and how we separate the task into smaller ones.
Experiences With Bottom-up Approach
When developing software with TDD, I often start with Bottom-up approach, which is creating small part or object that doesn’t had any dependent to other object and then move to bigger part that integrate other object we create before. Using this approach require us to know even to the smallest part that we want to build, I often map it as an entity, after that we integrate that entity to make a functional system. Problems I faced when using this approach is when we move to bigger part of the system, and we had different condition with our assumption when creating the small part it's require more effort to change the smallest part, because its functionality already completed.
Experiences With Top-down Approach
Recently I tried to develop some app with Top-down approach, I start working from the bigger part which is functionality to interact to the user, then I move to the smaller part of the functionality. If the bigger part need some dependent to other object, here I don't create another object until this one is finished, however I used interface to declare the contract and create the implementation later. The problem I had when develop with top-down approach is there is a lot of change when we start with the bigger one, also if our system had heavily nested object, its really hard to use interface or mock.
Conclusion
Both approach had pros and cons, based on my experience which is I don't use top down often, if your project had vertical complexity which means had a lot of nested object or functionality its better to use bottom-up, if your project had horizontal complexity which means there is a lot of functionality but not nested each other its better to use top down approach.
