Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
Transcript of TDD
Test-driven Development Test-driven development is an advanced development technique that uses unit tests to drive the design of the code. Definition: Motto:
Technique: Create a test and make it fail Make the test pass by any means necessary Change the code to improve the design while ensuring that all tests still pass Benefits: Forces developers to write Unit Tests Higher Test Coverage Safer to introduce Change Test suites can be run to ensure that the existing code is not broken through introduction of the change
The code is better designed, modular, with high cohesion and loose coupling Living Documentation Knowledge of system is captured in the Test Suite Better Design Testing drives the design of the code As a side effect, code is better designed due to decoupling necessary to create testable code. Higher Cohesion => Maintainable Code Responsibility of units of code is well-defined through tests.
Developers think about the software in terms of smaller units that can be written and tested idependently. Adoption TDD is not easy; many developers have prejudices against the practice TDD clearly has some
adoption Adopting TDD requires: Determined and skilled developers
Careful planning and follow-up
Strong management support
Mentoring Bugs are less costly Bugs are discovered as early as the time of writing the code Less defects Modularization loose coupling cleaner interfaces Tests cover every code path Because no more code is written than what is necessary to pass a failing test Example In order to add an "else" branch into an "if", developers first have to write a failing test case that motivates the branch. Tests are very thorough! If Adopted Properly: Increases productivity
Brings great level of confidence in their code
Brings courage to intorduce change
Eliminates need for memorizing how things work for future reference Living Documentation Developers move very quickly in an unhurried manner, to satisfy micro-goals. The scope of what they
have to think
about is reduced Sense of achievement is high! Vulnerabilities and Important Considerations Modular, Testable, Reusable Code When code relies on a Database, Web Service or any other external process or service, enforcing a unit testable separation, is a driving force to design more modular code. Interfaces Mock objects Not easy to do with testing false sense of security resulting in skipping integration testing. Since tests are written by the same
developer who codes,
they share the same as the code. blind spots misinterpretations
of requirements and High number of passing unit tests "could" create Interfaces or systems that depend on Databases Test suite itself is an overhead to the project Badly written or prone-to-failure tests are expensive to maintain If a poor architecture or test strategy
late changes that make
many of existing tests fail Those tests should be
Individually Fixed Deleting..... Disabling... Carelessly altering... Undetected holes in
Test Coverage for only 1 thing That is bad! Just to satisfy the test This is
desired! Refactor External systems Web Services Security infrastructures specific Network Configurations. , , , ,