CSC/ECE 517 Fall 2012/ch2a 2w31 up: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| Line 18: | Line 18: | ||
== <span style="color:#FF0000">Red</span> – <span style="color:#008000">Green</span> – Refactor == | == <span style="color:#FF0000">Red</span> – <span style="color:#008000">Green</span> – Refactor == | ||
=== Add a Test === | |||
* <b>Think about one thing the code should do :</b> The developer identifies a new functionality from the use cases and user stories, which contain detailed requirements and constraints. | |||
* <b>Capture that thought in a test, which<span style="color:#FF0000"> fails! </span> :</b> An automated test case (new or a variant of an existing test) is then written, corresponding to the new feature, taking into consideration all possible inputs, error conditions and outputs. Run all the automated tests. The new test inevitably fails because it is written prior to the implementation of the feature. This validates that the feature is rightly tested and would pass if the feature is implemented correctly, which drives a developer to the next step. | |||
=== Code | |||
• Write the simplest possible code that lets the | • Write the simplest possible code that lets the | ||
test pass! | test pass! | ||
Revision as of 20:05, 19 October 2012
SaaS - 5.3 - The TDD cycle: red-green-refactor
Introduction
Test Driven Development is an evolutionary approach to software development that requires a developer to write test code before that actual code and then write the minimum code to pass that test. This process is done iteratively to ensure that all units in the application are tested for optimum functionality, both individually and in synergy with others. This produces applications of high quality in less time.
TDD vs BDD
Advantages and Disadvantages
Advantages
ensures the code is tested and enables you to retest your code quickly and easily, since it’s automated.
Seams
Red – Green – Refactor
Add a Test
- Think about one thing the code should do : The developer identifies a new functionality from the use cases and user stories, which contain detailed requirements and constraints.
- Capture that thought in a test, which fails! : An automated test case (new or a variant of an existing test) is then written, corresponding to the new feature, taking into consideration all possible inputs, error conditions and outputs. Run all the automated tests. The new test inevitably fails because it is written prior to the implementation of the feature. This validates that the feature is rightly tested and would pass if the feature is implemented correctly, which drives a developer to the next step.
=== Code • Write the simplest possible code that lets the test pass! • Refactor: DRY out commonality w/other tests! • Continue with next thing code should do !
Examples
References
<references/>