CSC/ECE 517 Fall 2009/wiki2 6 TDD: Difference between revisions
| Line 31: | Line 31: | ||
A few advantages of TDD are: | A few advantages of TDD are: | ||
1. Unit tests prove that | 1. Unit tests prove that the code actually works. This implies that the code has fewer bugs. | ||
2. | |||
3. | 2. Allows to improve and change the design without breaking it. | ||
4. They demonstrate concrete progress. You don’t have to wait a month for 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. Of course, this is another distinction that traditional programming teaches us to ignore. “Done” doesn’t mean you’ve written the code and checked it in. “Done” means the code actually runs in the system without bugs. Running unit tests is a step closer to the latter. | |||
3. 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. | |||
4. They demonstrate concrete progress. You don’t have to wait a month for 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. Of course, this is another distinction that traditional programming teaches us to ignore. “Done” doesn’t mean you’ve written the code and checked it in. “Done” means the code actually runs in the system without bugs. Running unit tests is a step closer to the latter. | |||
5. Unit tests are a form of sample code. We all encounter library functions and classes we don’t know how to use. And one of the first places we go is the sample code. Sample code is documentation. But we don’t usually have samples for internal code. So we’re left sifting through the source or through the rest of the system. Because Bob, the guy who wrote that code, is no longer with the company, so we can’t actually ask him how it’s supposed to work. But unit tests are documentation. So when you can’t remember how to use class Foo, read the unit tests to find out. | 5. Unit tests are a form of sample code. We all encounter library functions and classes we don’t know how to use. And one of the first places we go is the sample code. Sample code is documentation. But we don’t usually have samples for internal code. So we’re left sifting through the source or through the rest of the system. Because Bob, the guy who wrote that code, is no longer with the company, so we can’t actually ask him how it’s supposed to work. But unit tests are documentation. So when you can’t remember how to use class Foo, read the unit tests to find out. | ||
6. 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. | 6. 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. | ||
Revision as of 01:23, 10 October 2009
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), and model driven (MDD). 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].
Responsibility Driven Development(RDD)
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. 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:
1. Unit tests prove that the code actually works. This implies that the code has fewer bugs.
2. Allows to improve and change the design without breaking it.
3. 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.
4. They demonstrate concrete progress. You don’t have to wait a month for 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. Of course, this is another distinction that traditional programming teaches us to ignore. “Done” doesn’t mean you’ve written the code and checked it in. “Done” means the code actually runs in the system without bugs. Running unit tests is a step closer to the latter. 5. Unit tests are a form of sample code. We all encounter library functions and classes we don’t know how to use. And one of the first places we go is the sample code. Sample code is documentation. But we don’t usually have samples for internal code. So we’re left sifting through the source or through the rest of the system. Because Bob, the guy who wrote that code, is no longer with the company, so we can’t actually ask him how it’s supposed to work. But unit tests are documentation. So when you can’t remember how to use class Foo, read the unit tests to find out. 6. 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. 7. Test-first reduces the cost of bugs. Bugs detected earlier are easier to fix. Bugs detected later are usually the result of many changes, and we don’t know which one caused the bug. So first we have to hunt for and find the bug. Then we have to refresh our memories on how the code is supposed to work, because we haven’t seen it for months. Then finally we understand enough to propose a solution. Anything that reduces the time between when we code the bug and when we detect it seems like a obvious win. We consider ourselves lucky to find out about bugs within a few days, before the code is shipped to SQA or to customers. But how about catching them within a few minutes? That’s what test-first accomplishes with the bugs it catches. 8. It’s even better than code inspections. Code inspections, they say, are better than testing, because using them to detect and fix bugs is cheaper than testing. After the code ships, it’s much more expensive to fix the bugs. The earlier we can detect and fix bugs, the easier and cheaper and better. That’s the advantage of having code reviews: Code inspections catch more bugs within a few days, rather than a few months. But test-first catches some bugs within a few minutes instead of a few days. It is even cheaper than code inspections. 9. It virtually eliminates coder’s block. Ever wonder what statement to write next? Like writer’s block, coder’s block can be a real problem. But test-first systematizes the structured part of coding, allowing you to concentrate on the creative part. You may get stuck on how to test the next bit or how to make the test pass, but you’ll never be left puzzling over where to go next. In fact, usually you’re left with the opposite problem: You know you need to take a break before you burn out, but you’re on a roll and don’t want to stop. 10. Unit tests make better designs. Testing a piece of code forces you to define what that code is responsible for. If you can do this easily, that means the code’s responsibility is well-defined and therefore that it has high cohesion. And if you 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. 11. It’s faster than writing code without tests! Or to put it another way, skipping unit tests is faster, unless you actually need the code to work. Most of the effort we spend on code, we spend fixing it after we’ve checked it in to the source-code repository. But test-first eliminates much of that waste by allowing us to get more of it right to start with and by making bugs easier to fix.
Behavior Driven Development(BDD)
Domain Driven Development(DDD)
Model Driven Development(MDD)
Conclusions
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