CSC/ECE 517 Fall 2009/wiki2 6 TDD
Survey of "Driven Development" Methodologies
Software Development Methodology
According to 1 :
"A software development methodology is a framework used to structure, plan, and control the process of developing a software system.[1]"
A software might range from a simple small application to a large and complex system in which the applications typically manage immense data sets and support complicated and extensive algorithms. Ad hoc approaches might sometimes work in developing small applications, because of the brilliance of the individuals developing it, but fails in most cases. Figure 1 shows the effects of an improper development methodology. A software development process has requirements. The things that an organization must understand are what software system will be developed, how much time would the development take, and what would be the quality of the final product. The amount and the way the software system meets the requirements determines the quality of a software system, Hence, a software development methodology is a critical tool for reaching these, complex and difficult to manage, requirements [2].
Below are a list of few software development approaches. Till date we have development approaches like responsibility driven (RDD), test driven (TDD), behavior driven (BDD), domain driven(DDD), model driven (MDD) and Responsibility Driven (RDD). All these approaches emphasize a core set of values and principles around which efficient software development practices, techniques, and tools have emerged. A developer should thoughtful choose among practices without losing their essence. But not all practices are congruent [3].
Test Driven Development(TDD)
Test Driven (TDD) methodologies emerged to combat the issues with traditional software development methodologies. Test Driven (TDD) methodologies are a part of programming methodologies referred to as Agile Software Development or Extreme Programming. These methodologies encourage a faster and iterative development cycle. TDD has many advantages over the typical waterfall development, such as improved black box testing performance, reduced code complexity, greater software quality, and greatly reduced test and debug time near the end of the development cycle[4].
The first step in Test Driven Development (TDD) methodology consists of writing unit tests for the system from the system requirements document that describes the functionality of the system. The first requirement for good TDD is to generate a set of exhaustive use cases that can be broken down into very small units of functionality, these are termed user stories.
Bellow is a template usually followed to write user stories:
As a <role> I want to <goal> so that <motivation>.
The following example user story reflects requirements for a funds transfer between two bank accounts:
As an account holder, I want to transfer funds between two of my accounts so that I can maximize the performance of my savings and avoid any fees associated with overdrafts and minimum balance rules.
Combining all of the user stories gives a complete and comprehensive set of requirements. The next step is to prioritize these user stories, for development, based on the criteria: importance, cost, time etc. The user stories should be so short that each story should not take much time to develop. Before any of the user story is designed or implemented a unit test case has to be designed for each of the user story. After the unit test is verified and validated as correct, the developer writes the code to meet the functionality and then unit tests it for correctness. Once the tests are run the code is improved by refactoring it and then testing it again. This step is repeated for each user story with all unit tests being run as often as possible, at each incremental change of the business logic code. By repeating tests and code cycle working software can be produced quickly and continuously [4]. Figure 2 depicts the TDD Model.
According to Martin Fowler TDD “gives you this sense of keeping just one ball in the air at once, so you can concentrate on that ball properly and do a really good job with it.” [6]
Advantages
A few advantages of TDD are [8]:
- Unit tests prove that the code actually works. This implies that the code has fewer bugs.
- Allows to improve and change the design without breaking it.
- With test cases developed before coding the developer knows exactly what the code needs to do therefore better adherence to the requirements and hence better quality.
- It is easy to track project progress. One doesn't have to wait a month tp see all the pieces of the system to come together. You can show progress even without a working system. Not only can you say you’ve written the code, you can actually demonstrate success.
- Test-first forces you to plan before you code. Writing the test first forces you to think through your design and what it must accomplish before you write the code. This not only keeps you focused, it makes for better designs.
- Test-first reduces the cost of bugs. Bugs detected earlier are easier and less expensive to fix than the ones detected later. TDD identifies the bugs early and fixing bugs is therefore easy and less costly too.
- Unit tests make better designs. Testing a piece of code allows the developer to define what that code is responsible for. If that can done easily, that means the code’s responsibility is well-defined and therefore that it has high cohesion. And if the developer can unit-test your code, that means you can bind it as easily to the test as to the rest of the system. Therefore, it has loose coupling to the pieces around it. High cohesion and loose coupling is the definition of good, maintainable design. Code that is easy to unit-test is also easy to maintain.
- It’s faster than writing code without tests.
Despite these advantages of TDD, traditional methods are still largely used. This is because of reluctance to large scale methodology change and because of the belief that TDD has some inherent disadvantages like the level of testing is unknown, wrong test cases might lead to reduction in quality etc.
Behavior Driven Development(BDD)
Behavior Driven Development(BDD) is a subtle refinement of TDD. It was developed by Dan North in the year 2003. Behavior Driven Development (BDD) like TDD is also an Agile software development technique, that lays importance on the collaboration between developers, testers and non-technical or business participants in a software project.
Behavior Driven Development (BDD) is an evolution in the thinking behind Test Driven Development(TDD).It brings together the good aspects from Test Driven Development and Domain Driven Design into an integrated whole. Therefore, making the relationship between these two powerful approaches to software development more evident.It aims to help focus development on the delivery of prioritized, verifiable business value by providing a common vocabulary that spans the divide between Business and Technology[13].
The BDD approach holds that an idea for a requirement can be turned into an implemented, tested, production-ready code only if the requirement is specific enough that everyone knows what is going on. To do this there has to be a way in which the requirements have to be specified so that the business, developers, testers and all the people working on the project have a common understanding of the requirement. In the BDD approach just like TDD, a BDD "story" is developed, featuring a description of a requirement, a business benefit, and criteria for completeness.
The three core principles behind Behavior Driven Development (BDD) are [13]:
- Both the Business and Technology should refer to the same system in the same way
- Any system should have an identified, verifiable value to the business
- Up-front analysis, design and planning all have a diminishing return
BDD relies on the use of a very specific (and small) vocabulary to minimize miscommunication and to ensure that everyone – the business, developers, testers, analysts, managers and all the non-technical staff – are not only on the same page but using the same words.
Domain Driven Development(DDD)
Domain Driven Development(DDD) is about mapping business domain concepts into software artifacts. The premise of domain-driven design is two-fold [11]:
* For most software projects, the primary focus should be on the domain and domain logic; and * Complex domain designs should be based on a model.
A few advantages of DDD methodology are:
- It helps the development team create a common model, between the business and IT stakeholders in the company. This model can be used by the team to communicate about the business requirements, data entities, and process models.
- The model is modular, extensible and easy to maintain as the design reflects the business model.
- It improves the reusability and testability of the business domain objects.
Model Driven Development(MDD)
"Model Driven Development (MDD) refers to the systematic use of models as primary engineering artifacts throughout a software development life cycle." [10]
The use of models increases the level of abstraction and introduces separation of concerns through different types/layers of models. Therefore MDD methodology allows more early aspects analysis and helps achieve adaptability, portability and reusability through these models. MDD also makes software development activities, including evaluation, more systematic and formal [10].
A few advantages of MDD are [9]:
- Quality improvement (performance, availability, security, modifiability, scalability, reliability) by using well establishedand tested transformations.
- Time savings by code generation.
- Using MDD cross-platform development and enhanced platform migration can be done easily.
- Models can be used to improve communication and interaction between different domain experts.
Despite these advantages MDD is considered, by a few, a too formal approach to follow.
Responsibility Driven Development(RDD)
Responsibility-Driven Design is a way to design that emphasizes behavioral modeling using objects, responsibilities and collaborations. In a responsibility-based model, objects play specific roles and occupy well-known positions in the application architecture. Each object is accountable for a specific portion of the work. They collaborate in clearly defined ways, contracting with each other to fulfill the larger goals of the application. By creating a "community of objects", assigning specific responsibilities to each, you build a collaborative model of our application. In simple words RDD emphasizes on "testing interactions rather than state changes"
Responsibility-Driven Development (RDD) involves:
- developing the actions and activities for which our software is responsible
- developing the responsibilities in terms that both users and developers can understand
- developing software objects that implement those responsibilities
References
[1] http://en.wikipedia.org/wiki/Software_development_methodologies
[2] Larry Trussell, “Essential Software Development Methodology”, Power Engineering Society 1999 Winter Meeting, IEEE ,31 Jan.-4 Feb. 1999 Page(s):357 - 361 vol.1.
[3] Wirfs-Brock, R.J.;” Driven to ... Discovering Your Design Values”, IEEE Software, Volume 24, Issue 1, Jan.-Feb. 2007 Page(s):9 - 11
[4] Fraser, J.; Mattu, B.S.; "Test Driven Design Challenges for Faster Product Development", Systems Conference, 2007 1st Annual IEEE 9-13 April 2007 Page(s):1 - 5
[5] http://www.agiledata.org/essays/tdd.html
[6] M. Fowler, Test-Driven Development by Example, Addison-Wesley, 2003.
[7] Mugridge, R.; "Test driven development and the scientific method" Agile Development Conference, 2003. ADC 2003. Proceedings of the 2003 Page(s):47 - 52
[8] http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first?t=xp
[9] Streitferdt, D.; Wendt, G.; Nenninger, P.; Nyssen, A.; Lichter, H.; "Model Driven Development Challenges in the Automation Domain", Computer Software and Applications, 2008. COMPSAC '08. 32nd Annual IEEE International
[10] Liming Zhu; Yan Liu;"Model Driven Development with non-functional aspects", Aspect-Oriented Requirements Engineering and Architecture Design, 2009. EA '09. ICSE Workshop on 18-18 May 2009 Page(s):49 - 54
[11] http://domaindrivendesign.org/resources/what_is_ddd