Test Driven Design & Top Down Design


The top-down approach starts with the big picture of the problem domain (the top) where it creates the high-level abstraction and works down to implement the code. Such approach advocates the traditional object-oriented design, where the complexity of the problem domain can be best understood by starting with an abstraction and then it decomposes the problem into smaller units. With such approach the problem domain is viewed from the big picture, and the application development starts by developing the application architecture where it is prepared before the code is developed and can be tweaked as the code goes through a development progress (Kraus, 2006).

Test Driven Design (TDD) is a design technique that ensures that the source code went through aggression unit testing where the test code is written before the actual functional code to guarantee the best design of implementing specific functionality within the system. While in traditional testing defects can be found within written code for certain functionality during the unit testing, the TDD can improve the quality of the design and the written code by measuring the success of such code when it is no longer failing the unit tests that’s written before implementing the source code. TDD technique provides the working specifications of the functional code for specific system’s functionality where such unit tests become a significant portion of the software technical documentation. Also, with such approach the acceptance tests can represent the requirements documentation that explain the stakeholders’ expectations of the system and specify the critical requirements of such system (Ambler, 2002).

Top-Down Design

There are two methods for developing application code: bottom-up and top- down approaches where each method offers different perspective of the development approach and the usage of any of such approaches can be determined by case-by-cases basis. In the top-down approach, the application development is achieved through an iterative decomposition of the problem domain. Also, with such approach the system is first put together in the first level subsystems without specific details, and then each subsystem is refined in more details (Kraus, 2006).

The top-down approach is accomplished by breaking the system into sub-systems to gain insight of its sub-systems structures. Each sub-system is then refined to a better details. Such approach promotes a complete understanding of the system and planning to what is required to be done. However, such approach delays testing of the functional units until a significant design is complete. On the other hand, bottom-up approach promotes coding and early testing. The design of the modern software usually combined both approaches, however understanding of the complete system usually leads to the top- down approach, while the pre-existing modules and existing code can give the design the bottom-up flavor (WorldLingo.com, 2011).

WorldLingo.com (2011) explained that the following are the advantage of the top-down approach:

  • Module design where the development is turned to be self contained is created due to separating the low level work from the higher level objects.
  • Less time consuming in the development since each developer is involved in only a part of the big project.
  • Such approach makes the project processing becomes optimized since developers have to apply the knowledge and the experience to their parts.
  • Such approach makes the final product easy to maintain since it is easy to identify the errors generated from the module of the entire program.


Test Driven Development

The big advantage of the TDD approach is that it allows small steps in writing the software where it can be more productive than the attempt of writing large steps of code. With such approach, it’s much easier to find defects of few lines of code instead of thousands of lines of code that developers has to go through to find where the defects within these line of codes. With smaller steps, it is faster for the regression test to be achieved, and it’s more productive to proceed with smaller steps in writing certain functionality. Writing the unit test represents an act of design and documentation than verification (Ambler, 2002).

In applying the test-driven development, the whole system is partitioned into subsystems and the system interfaces is designed in chunks that will be created as classes without writing code where the work is created in an incremental design that can take small step at a time. In each small step, a micro-goal piece of work is done by creating the test-first design for it, and then writing the code that satisfy the test once it is passed. Such approach reduces the scope of work, and the micro-piece of work is done when the test is passed during the refactoring of the code for better design, and then the move can be made to the next piece of responsibility that can accomplish certain functionality within the system (Venners, 2002).

George and Williams (2003) explains that TDD starts with some thoughts of the functionality of the requirements which will be tested. Once the test cases are written that generally will not compiled, the software developers will write and implement the code that will pass the test cases. The work will continue to grow as the developer will be adding more of the functionality at consistent rate where all the test cases that required for the entire program must successfully pass before any new code can be considered to be fully implemented. The following are the benefits of such approach:

  • The TDD approach produce a better code quality since such quality is measured by the compliance of such code to the test cases when it’s compared with the traditional waterfall model practice.
  • TDD approach facilitates simpler design than other approach; however the transition of such approach mindset is difficult for many developers.
  • Developers using the TDD approach will produce a faster code with better quality than the traditional waterfall-like approach.

Maier (2009) explained that TDD is the technique that is used in the software development where it uses short development iterations that are based on pre-written test cases which defined the desired new functions or improvement of the software systems. Each iteration will produce the necessary code to pass such iteration’s test where the development team refactoring the code to accommodate changes. The TDD is linked to agile development where the code is built during small iterations (agile) to meet the tests (test-driven). The TDD increasing the application usability since the users of such application will have the chance to test the functionality within the system during the iterations that will increase the product flexibility since the test-driven is always trying to accomplish the following:

  • Focus on the user needs.
  • Define the desired functionality, and
  • It doesn’t describe either user-interfaces or application interfaces.

Test Driven Design promotes the general technique of having a complete automated unit tests for functional requirement, develops the code for testing, and helps improving such code through iterative improvement with code refactoring and rewriting. However, TDD pins down the code too early, and it ignores certain classes of essential unit tests. TDD promotes the test first approach, where the developer first writes the test cases that defined the desired new function or improvement, and then produce the code that should work to pass such test and that required refactoring of such code to pass such test. However, the automated tests should not be implemented until the cost/benefit ratio makes the test worthwhile where it’s rarely to be at the start of the code. Also, the test is guided by the code and the knowledge of where the failure cases that might be existed within the code (Dalke, 2010).

Test Driven Design doesn’t give the confidence that the code works because it excludes the idea of adding the unit tests that are expected to pass. TDD is one technique for learning the skills of developing unit tests but it is not an essential technique. Also, TDD advocates claim that TDD can lead to 100% test coverage, however such claim ignored the fact that code refactoring that might happen will create a new code that never been tested. In addition TDD freezes the test-cases for API too early, and in many cases, the API changes often, and such changes requires the changes to all the test cases in place (Dalke, 2010).


A top-down development approach is on of the two commonly methods used for application development where the other approach is the bottom-up method. In such approach, the process starts by looking at the high-level abstraction of the problem domain, and works downward to implementing the application code. The approach follows the traditional object-oriented design and it advocates that understanding the problem complexity starts by decomposing the problem into small units. However, in many cases such approach becomes a problematic, and it becomes more productive to start with the basics and work upward which leads to the bottom-up approach (Kraus, 2006).

Finally, Test Driven Development (TDD) is an approach that is used in the software development practice where the test cases are written prior to the code implementation. In such practice the implementation of the system is starting from the objects unit test cases where writing such cases can trigger the need for other objects’ methods. The rule of thumb of such approach is if the test cases can’t be written for certain functionality, the code for such functionality shouldn’t be written. Such approach can make the code less coupling and more cohesive than having a code without having the testing as part of the coding cycle. Reducing coupling occurs because the objects needed to pass the test based on the requirements are the ones that are used in such process instead of building objects based on possible improper understanding of requirements (George and Williams, 2003).


Ambler, S. (2002) Introduction to Test Driven Design (TDD) [Online]. Available from: http://www.agiledata.org/essays/tdd.html (Accessed: 18 March 2011).

Dalke, A. (2010) Problems with TDD [Online]. Available from: http://www.dalkescientific.com/writings/diary/archive/2009/12/29/problemswithtdd.html (Accessed: 18 March 2011).

George, B. & Williams, L. (2003) A structured experiment of test-driven development [Online]. Available from: http://citeseerx.ist.psu.edu/viewdoc/download?doi= (Accessed: 18 March 2011).

George, B. & Williams, L. (2003) A structured experiment of test-driven development [Online]. Available from: http://citeseerx.ist.psu.edu/viewdoc/download?doi= (Accessed: 18 March 2011).

Kraus, A. (2006) Development Methods: Top-Down and Bottom-Up Method [Online]. Available from: http://ezinearticles.com/?Development-Methods:-Top-Down-and-Bottom-Up-Method&id=270411 (Accessed: 18 March 2011).

Maier, A. (2009) How Test-Driven Development Increases Overall-usability [Online]. Available from: http://www.uxbooth.com/blog/how-test-driven-development-increases-overall-usability/ (Accessed: 18 March 2011).

Venners, B. (2002) Test-Driven Development [Online]. Available from: http://www.artima.com/intv/testdriven.html  (Accessed: 18 March 2011).

WorldLingo.com (2011) Top-down and bottom-up design [Online]. Available from: http://www.worldlingo.com/ma/enwiki/en/Top-downandbottom-updesign (Accessed: 18 March 2011).


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: