Driving Quality with TDD

1,444 views

Published on

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,444
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
18
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Driving Quality with TDD

  1. 1. Driving Quality with TDD Steven Mak 麥天志 steven@odd-e.com www.odd-e.com Thursday, 6 May 2010
  2. 2. About me • Steven Mak 麥天志 • Agile Coach at Odd-e • Lives in Hong Kong • I do speak Mandarin! • Agile, TDD Coaching • Love to code Thursday, 6 May 2010
  3. 3. Agenda • Why you care? • What you can do? • How to implement? Thursday, 6 May 2010
  4. 4. Sacrificing quality with Legacy Code 4 Thursday, 6 May 2010
  5. 5. 5 OK, I don’t want Legacy Code • Don’t write legacy code • Improve development skills • Clean up your neighbourhood • Write both high-level and unit tests • Raise awareness of the negative impact Thursday, 6 May 2010
  6. 6. 6 Boy Scout Rule • If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot Valuecode/designquality Time effortneededforchange Time Thursday, 6 May 2010
  7. 7. 7 What is “testing” anyway? • What do you need to do before you can ship your product? • Simple testing classifications! – Customer-facing tests, whether the requirements are fulfilled – Developer tests, system does what the developer intended Thursday, 6 May 2010
  8. 8. 8 Professionalism Thursday, 6 May 2010
  9. 9. Test Driven Development 9 Thursday, 6 May 2010
  10. 10. 10 We need Unit Tests • New Functionality • Fix problems • Improve design • Optimise resources • “Edit and Pray” or “Cover and Modify”? Thursday, 6 May 2010
  11. 11. 11 Good Unit Tests • Fast • Localise problems • Readable • One assertion per tests • Don’t forget higher level/Customer-facing tests Thursday, 6 May 2010
  12. 12. 12 What is not unit tests • It talks to database • It communicates across a network • It touches the file system • It requires special things to be done in your environment (e.g. editing configuration files) Thursday, 6 May 2010
  13. 13. 13 Test Driven Development • 1 Rule – Only ever write code to fix a failing test • 3 Steps – Write a test (which is “red”) – Code (to make test pass “green”) – Refactor (test still pass “green”) Thursday, 6 May 2010
  14. 14. 14 What is Refactoring? • A series of small steps, each of which changes the program’s internal structure without changing its external behaviour Thursday, 6 May 2010
  15. 15. 15 Refactoring • Explain by analogy – Tidy up at home – Cleaning hands after surgery • Refactoring Workbook – Bill Wake • Aware of code smells • Relentlessly refactoring • Any tools available? • Don’t forget refactoring tests Thursday, 6 May 2010
  16. 16. 16 • Duplicated Code • Long Method • Large Struct/Class • Long parameter list • Switch statements • Comments Code Smells Thursday, 6 May 2010
  17. 17. 17 • No, you still want to do modelling... • Design workshop • Model to have a conversations • Joint design workshops for broader design issues • Technical leaders teach at workshops I heard that we don’t need modelling with TDD...? Thursday, 6 May 2010
  18. 18. 18 CI is a developer practice • CI is not merely about a tool • Encourage splitting changes into small increments • TDD fits well with CI practice • Shaming people has a negative effect Thursday, 6 May 2010
  19. 19. 19 Slow Build? • Add hardware • Parallelize • Change tools • Incremental Build • Incremental Deployment • Manage dependencies Thursday, 6 May 2010
  20. 20. Can I start on the next Monday? 20 Thursday, 6 May 2010
  21. 21. 21 Convincing your boss (or yourself) • Cost of bug fixing is lower if it is found earlier • In 2008, Case study of TDD at IBM and Microsoft shows that TDDers enjoy a defect density reduction ranging from 30% to 90% and a productivity cost of between 15% and 35% http://research.microsoft.com/en-us/projects/esm/ nagappan_tdd.pdf • Kent Beck: “If it doesn’t have to work, I can get it done a lot faster!” Thursday, 6 May 2010
  22. 22. 22 So you want to start? • Get the team members started writing a few automated tests before trying to drive their code with tests • Spend time working with the team to understand the real state of the code, the level of experience of the team members, and how interested each of them is in making changes to the way they work • The team needed to work together to establish a test strategy and to agree on how they would organise their tests into a shared suite that anyone in the team could run Thursday, 6 May 2010
  23. 23. 23 Buy-in from the Team • It takes time for the team to learn, allow time in their planning for learning • Any compelling reasons before they will commit to making on the extra work of writing automated tests? • Most team begins with: – Write tests for new code and any changes to existing code • Discuss with the team and see if they are committed to do this • Target of writing a few tests every day Thursday, 6 May 2010
  24. 24. 24 Coding Dojo Thursday, 6 May 2010
  25. 25. 25 A lots of coaching! • No structure in place to decide when and with teams to work? • Internal coaches were asked to do normal development? • Not listening to internal coaches? • Coaching skills not appreciated and further developed? • Both internal and external coaching! Thursday, 6 May 2010
  26. 26. 26 Sustaining TDD • One-line changes accumulate and turn into legacy code • Make test coverage more visible • Look for new areas of their architecture that they don’t have tests for – UI? – Logs? – Print outs? Thursday, 6 May 2010
  27. 27. 27 Test smells • Pay attention to the time it takes to build the application and run the tests • Watch out for poorly designed tests and its dependencies • Isolate long running tests into a separate test suite that is run in the background Thursday, 6 May 2010
  28. 28. 28 Maintain Test-First Discipline • Working in pairs to discuss design • Write automated tests and achieve a similar level of test coverage as a trial period Thursday, 6 May 2010
  29. 29. 29 Pair Programming helps reinforcing test first discipline • Ping-Pong programming • Videos of how others do • Think it aloud • How Pair Programming Works: – http://www.computer.org/cms/Computer.org/ComputingNow/homepage/ 2010/0110/W_SW_PairProgramming.pdf Thursday, 6 May 2010
  30. 30. 30 No Test tools Available? • Use Open source unit test frameworks whenever available • It is not impossible to write a simple automated test framework or variant to fit your needs Thursday, 6 May 2010
  31. 31. 31 Examples of UT frameworks • C/C++ - CppUTest • Java - JUnit • .Net - NUnit • PHP - PHPUnit • Python - PyUnit • Ruby - Test::Unit, RSpec Thursday, 6 May 2010
  32. 32. 32 is TDD only for new projects? • Identify change points • Find test points • Break dependencies • Write tests • Make changes and refactor Thursday, 6 May 2010
  33. 33. 33 Fixing Broken Windows • Talk to the developers individually about what’s bothering them most to look for really bad code and it’s too overwhelmed to clean up • Help them form a plan of action to renovate the code • Recognising the problem and breaking it down into bite-size pieces • Collective Code Ownership Thursday, 6 May 2010
  34. 34. 34 I got hardware, can I... ? • Dual targeting • Run tests on development environment • Run tests on real hardware to discover differences, endian, memory models... • OS abstraction layer • Simulation layers • Lots of stubs, plus dependency injection • Learning tests Thursday, 6 May 2010
  35. 35. 35 References Working Effectively with Legacy Code 修改代码的艺术 - Michael Feathers Practical TDD and ATDD for Java Developers - Lasse Koskela Clean Code 代码整洁之道 - Robert Martin Practices for scaling Agile and Lean practices - Craig Larman and Bas Vodde Growing OO Software, guided by tests - Steve Freeman xUnit Test Patterns - Gerard Meszaros Agile Coaching - Rachel Davis and Liz Sedley Thursday, 6 May 2010
  36. 36. 36 Questions? Steven Mak 麥天志 steven@odd-e.com www.odd-e.com Thursday, 6 May 2010

×