Tdd
0 likes283 views
TDD is a software development technique where unit tests are written before production code to define desired functionality. The TDD cycle involves writing a test that fails, then code to pass the test, and refactoring code while ensuring tests still pass. This forces critical analysis and design while providing a safety net of regression tests. Benefits include feedback that code works, tests as documentation, and improved design through loose coupling and refactoring with confidence from tests.
Tdd
- 1. Test Driven Development Dmitry Savin
- 2. Introduction • TDD is an advanced technique of using automated unit tests to drive the design of software and force decoupling of dependencies. • The result of using this practice is a comprehensive suite of unit tests that can be run at any time to provide feedback that the software is still working. • Was invented by Kent Beck at 1999.
- 3. TDD cycle • Write a test that fails. • Write just enough code to pass the test. • Clean up code (remove duplication, improve the design) and ensure that all tests still pass.
- 4. Write a test that fails • Imagine how the new code should be called and write the test as if the code already existed. • Create the new production code stub. Write just enough code so that it compiles. • Run the test. It should fail. By this you ensure that test is calling the correct code and that the code is not working by accident. Note Now we have the goal - make this test pass. This helps us concentrate our attention on one particular task.
- 5. Write just enough code to pass the test • Write the production code to make the test pass. Keep it simple. • You can hard-coding of the expected return value first to verify that the test correctly detects success. • If you've written the code so that the test passes as intended, you are finished. • The test is the objective definition of “done.” • The phrase "You Ain't Gonna Need It" (YAGNI) is often used to veto unnecessary work. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
- 6. Clean up code and ensure that all tests still pass • Remove duplication caused by the addition of the new functionality. • Make design changes to improve the overall solution. • After each refactoring, rerun all the tests to ensure that they all still pass.
- 7. Process Example • Follow these steps (slight variations exist among TDD practitioners): • Understand the requirements of the story, work item, or feature that you are working on. • While working on task you can edit your test list - it is list of tests which you want to create. • Red: Create a test and make it fail. • Green: Make the test pass by any means necessary. • Refactor: Clean up code and ensure that all tests still pass. • Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/Refactor cycles.
- 8. Benefits of TDD • The suite of unit tests provides constant feedback that each component is still working. • The unit tests act as documentation that cannot go out-of-date, unlike separate documentation, which can and frequently does. • When the test passes and the production code is refactored to remove duplication, it is clear that the code is finished, and the developer can move on to a new test. • Test-driven development forces critical analysis and design because the developer cannot create the production code without truly understanding what the desired result should be and how to test it. • The software tends to be better designed, that is, loosely coupled and easily maintainable, because the developer is free to make design decisions and refactor at any time with confidence that the software is still working. This confidence is gained by running the tests. • The test suite acts as a regression safety net on bugs: If a bug is found, the developer should create a test to reveal the bug and then modify the production code so that the bug goes away and all other tests still pass. On each successive test run, all previous bug fixes are verified. • Reduced debugging time!
- 9. Characteristics of a Good Unit Test • Runs fast. • If the tests are slow, they will not be run often. • Separates or simulates environment dependencies such as databases, file systems, networks, queues, and so on. • Otherwise they will not run fast, and a failure does not give meaningful feedback about what the problem actually is. • Use stubs and mock objects. • Is very limited in scope. • If the test fails, it's obvious where to look for the problem. • Use few Assert calls so that the broken part of code is obvious. • It's important to only test one thing in a single test. • Tests should run and pass on any machine. • Clearly reveals its intention. • Another developer can look at the test and understand what is expected of the production code.
- 11. References • Microsoft: Guidelines for Test-Driven Development • https://msdn.microsoft.com/en-us/library/aa730844%28v=vs. 80%29.aspx • MCE 2014: Jon Reid - Test Driven Development for iOS (and anything) • https://www.youtube.com/watch?v=Jzlz3Bx-NzM