Test Driven Development Part 2
Download as PPT, PDF0 likes380 views
The document discusses Test Driven Development (TDD) and provides details on: 1. The three rules of TDD which require writing failing tests first and only producing minimal production code to pass each test. 2. Refactoring as an important part of TDD to refine code design as new tests are added and production code is incremented. 3. Code smells which are surface indications of deeper problems like duplicated code, long methods, and large classes that should be refactored.
Test Driven Development Part 2
- 1. Test Driven DevelopmentTest Driven Development Part 2 Gamal ShaabanGamal Shaaban International Centers Orange Labs Cairo Mobile Applications & Software Development
- 3. 3 Orange restricted Session-2Session-2 3 • The Three Rules Of TDD • Legacy Code & Refactoring • Code Smells • Coupling And Cohesion • Continues Integration
- 4. 4 Orange restricted THE THREE RULES OF TDD 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test. http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd 4
- 5. 5 Orange restricted RefactoringRefactoring Refactoring is one of the most important parts of TDD, which means you need to refine the code design as you add new tests. Refactoring should be done consistently as you increment the software, adding tests and production code. Make code easier to maintain in the future Use IDE when possible to do refactoring. Refactor Without Fear. 5
- 6. 6 Orange restricted Code SmellsCode Smells A code smell is a surface indication that usually corresponds to a deeper problem in the system. Martin FowlerMartin Fowler http://martinfowler.com/bliki/CodeSmell.html 6
- 7. 7 Orange restricted Smells To BeSmells To Be RefactoredRefactored 1.Duplicated Code 2.Long Method 3.Large Class 4.Long Parameter List 5.Divergent Change 6.Lazy Class 7.Speculative Generality 8.Temporary Field 9.Data Class 10.Refused Bequest 11.Comments 12.MiddleMan
- 8. 8 Orange restricted COUPLING ANDCOUPLING AND COHESIONCOHESION Maximize internal interaction (cohesion) • easier to understand • easier to test Minimize external interaction (coupling) • can be used independently • easier to test • easier to replace • easier to understand 8
- 9. 9 Orange restricted 9 Degree of dependence among components No dependencies Loosely coupled-some dependencies Highly coupled-many dependencies
- 11. 11 Orange restricted CONTINUES INTEGRATION
- 12. 12 Orange restricted • Teams integrate their work multiple times per day. • Each integration is verified by an automated build • Significantly reduces integration problems • Develop cohesive software more rapidly Source: Martin Fowler
- 13. 13 Orange restricted Five Principles of Continuous Integration • Environments based on stability • Maintain a code repository • Commit frequently and build every commit • Make the build self-testing • Store every build 13
- 14. 14 Orange restrictedOrange presentation Questions?
- 15. thanks
Editor's Notes
- #3: “TDD Intro” Is all code guilty until proven innocent??? can we find out?
- #8: Duplicated Code :bad because if you modify one instance of duplicated code but not the others, you (may) have introduced a bug! Long Method :long methods are more difficult to understand performance concerns with respect to lots of short methods are largely obsolete Large Class: classes try to do too much, which reduces cohesion Long Parameter List : hard to understand, can become inconsistent Divergent Change: Related to cohesion: symptom: one type of change requires changing one subset of methods; another type of change requires changing another subset Lazy Class : A class that no longer “pays its way” e.g. may be a class that was downsized by a previous refactoring, or represented planned functionality that did not pan out Speculative Generality : “Oh I think we need the ability to do this kind of thing someday” Temporary Field : An attribute of an object is only set in certain circumstances; but an object should need all of its attributes More: http://c2.com/cgi/wiki?CodeSmell http://www.industriallogic.com/wp-content/uploads/2005/09/smellstorefactorings.pdf
- #11: http://stackoverflow.com/questions/39946/coupling-and-cohesion
- #14: Environments based on stability Maintain a code repository Commit frequently and build every commit Make the build self-testing Store every build