CSC/ECE 517 Fall 2012/ch2a 2w31 up: Difference between revisions
Jump to navigation
Jump to search
| Line 31: | Line 31: | ||
=== Iterate === | === Iterate === | ||
* Continue with the next thing (new or improvement of a feature), the code should do. | * Continue with the next thing (new or improvement of a feature), the code should do. | ||
* Aim to have working code always | * Aim to have working code always. | ||
==Examples== | ==Examples== | ||
Revision as of 20:37, 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.
Implement the feature
- Write the simplest possible code that lets the test pass : Minimal code is written to make the test pass. The entire functionality need not be implemented in this step. It is not uncommon to see empty methods or methods that simply return a constant value. The code can be improved in the next iterations. Future tests will be written to further define what these methods should do. The only intention of the developer is to write "just enough" code to ensure it meets all the tested requirements and doesn't cause any other tests to fail. <ref>What is Test Driven Development?</ref>
Run the tests again. Ideally, all the tests should pass, making the developer confident about the features implemented so far.
Refactor
- DRY out commonality with other tests : Remove duplication of code wherever possible. Organizational changes can be made as well to make the code appear cleaner so it’s easier to maintain. TDD encourages frequent refactoring. Automated tests can be run to ensure the code refactoring did not break any existing functionality
Iterate
- Continue with the next thing (new or improvement of a feature), the code should do.
- Aim to have working code always.
Examples
References
<references/>