The Road to Test Driven Development

  • 1,273 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,273
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
44
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. The Road To Test-Driven Development By Christopher Paulicka Software Engineering Manager
  • 2. Introduction
    • Not just what Test-Driven Development is…
    • But also how to get to Test-Driven Development
  • 3. Agenda
    • What is Test-Driven Development
    • One (Abstract) Road to Test-Driven Development
    • Your Road to Test-Driven Development
    • My Road to Test-Driven Development
  • 4. Vocabulary
    • Test-Driven Development – TDD
    • Extreme Programming - XP
  • 5. Thanks
    • Perl Mongers for showing up!
    • Oversee.net for the nice space
    • Michael Lee, Director of Engineering, for “volunteering” me
    • All the development team here at Oversee for feedback
  • 6. The Three Participants
    • Christopher Paulicka
    • Oversee.net
    • Perl Mongers
  • 7. Christopher Paulicka
    • Software Development – 16 years
    • Testing – 10 years
    • Perl – 4 years
    • Test-Driven Development – 1 year
  • 8. Oversee Development Environment
    • Agile/Scrum
    • Perforce
    • Linux/Apache/MySQL/Perl, RPM
    • Mason/Catalyst, DBI
    • Test::More, Test::MockObject
    • Test::Unit, Test::WWW::Selenium
    • Module::Build, CPAN2RPM
  • 9. Perl Mongers
    • Perl aficionados
    • Please ask questions at any time
    • What’s your testing experience?
  • 10. What is TDD
    • TDD is old, but kind of new
    • Test first, but still follow requirements
    • Part of Agile/XP, but reusable anywhere
  • 11. Important to Know
    • History of TDD in Extreme Programming
    • History of Scrum at Oversee
  • 12. Software Development Methodologies
    • Hack
    • Waterfall
    • Agile
  • 13. Waterfall Development
    • Requirements
    • Design
    • Implement
    • Test
    • Maintain
  • 14. Waterfall Costs
    • Rigid design
    • High change costs
    • Requires expert designers up front
  • 15. Examples of Agile Methodologies
    • Extreme Programming
    • Scrum
    • Crystal Clear
    • Feature Driven Development
    • Adaptive Software Development
    • DSDM
  • 16. Extreme Programming
    • Test-Driven Development
    • Continuous Integration
    • Pair Programming
    • Refactoring
  • 17. Cost of Feedback
  • 18. Test-Driven Development
    • Pick a Feature
    • Write a Test for that Feature
    • Run all Tests and see new Test Fail
    • Write Code for Feature
    • Run all Tests and see all Tests Pass
    • Refactor
    • Repeat
  • 19. A Bit More About Refactoring
    • Refactor the Code
    • Refactor the Tests
    • Refactor the Documentation
    • Refactor the Design
  • 20. Who owns testing?
    • QA
    • Deploy
    • Systems
    • Development
  • 21. Types of Testing
    • Requirements Tests
    • Integration Tests
    • System Tests
    • Development Tests
  • 22. Types of Development Testing
    • Unit Tests
    • Regression Tests
  • 23. One Possible Road to TDD
    • Test to Verify
    • Test for Regression
    • Test for Design
    • Test-Driven Development
  • 24. Test To Verify
    • Problem arises
    • Write throw away test
    • Disposable code modifications
      • Logging
      • Dumping, etc
    • Simple and Fast
    • Gone forever…
  • 25. Why Do We Do That?
    • Habit
    • Speed
    • Anticipation (almost done…)
  • 26. Test for Regression
    • Problem arises
    • Write reusable test that duplicates problem
    • Keep regression test
    • Run regressions anytime
  • 27. Good, but Good enough?
    • Bug driven
    • Prevents regressions
    • Run tests anytime in development
    • Focused late in the curve
    • Expects test framework
  • 28. Test for Design
    • Design API
    • Write Code
    • Write Tests
    • Refactor
  • 29. Development Test Processes
    • Piece-wise Test Last
    • Lump-sum Test Last
    • Test First aka TDD
  • 30. Test-Driven Development
    • As Beck said in XP
      • Good Rules, lead to
      • Good Behavior, which give
      • Good Unit Tests
  • 31. Rules
    • Write code only when test fails
    • Eliminate duplication afterwards
  • 32. Behaviors
    • Organic Design
    • Writing own tests
    • Rapid response
    • Modular Design
  • 33. Good Unit Tests
    • Run fast
    • Run in isolation
    • Easy to understand
    • Use real data
    • Incremental step (not too large)
  • 34. Your Road To TDD
    • Why TDD
    • Cost/Benefit Analysis
    • How To Start
  • 35. Why Test Driven Design
    • Tests as Use Cases
    • Tests as Documentation
    • Tests as Design
  • 36. Possible reasons to avoid TDD
    • Tests are programmer focused
    • May not be requirement focused
    • Running all tests are slow
    • Sprinting
    • Refactoring
    • Comparing
  • 37. Cost/Benefit of TDD
    • Industry Analysis
    • Personal Analysis
  • 38. Benefits - Industry Analysis
    • Reduce development lead-time significantly
    • Programmers that write tests are more productive
    • Rarely use a debugger
    • Easy to revert on test failure
  • 39. Benefits – Industry Analysis (cont)
    • Programmers tests interface first, then code
    • Shorter implementation time
    • High Code coverage
    • Regressions
    • More modular code
  • 40. Costs – Industry Analysis
    • More code
      • Though higher productivity with TDD
    • Costly test setup
      • UI
      • DB
      • Multithreaded
    • Large legacy code bases
  • 41. Metrics – Industry Analysis
    • TDD code passed 18 - 50% more external test cases than control group code
    • TDD code had 10 – 50% less time spent debugging code
    • TDD had from 0 - 16% decrease in productivity (in lines of non-test code)
  • 42. Metrics – Industry Analysis (cont)
    • TDD has 163% more asserts/module
    • TDD 2-3x higher test coverage
      • line and condition coverage near 100%
    • TDD coders spent 13% less time producing solutions that were 12% larger then control (including tests!)
  • 43. Subjective – Industry Analysis
    • After the study, when asked:
    • TDD would stick with TDD
    • TLD would go to TDD (60%+)
    • No tests would go to TLD
  • 44. Benefits – Personal Analysis
    • Senior/Junior Developer Interaction
      • Senior approve tests/API
      • Junior implements API
      • Senior code reviews, done
    • Tests as Use Cases
    • Test Documentation more stable then Code Documentation
  • 45. Costs – Personal Analysis
    • More code
      • Though happier with more feedback
    • Costly test setup
      • UI - WWW::Mechanize
      • DB – Test::MockObject
      • Multithreaded - …heh…yes.
    • Large Legacy Codebases are painful, but TDD may be very beneficial…it’s a start!
  • 46. How To Start
    • Believe in Testing
    • Test Framework
    • Test Coverage
    • Write Tests First
  • 47. Believe in Testing
    • If it's worth building, it's worth testing.
    • If it's not worth testing, why are you wasting your time working on it?
  • 48. Test Frameworks
    • Perl has a lot…
    • Test::Simple
    • Test::More
    • Test::Unit
  • 49. Test Coverage
    • Provide metrics
    • Devel::Cover
  • 50. Write Tests First
    • Code review tests
    • Pair program tests
    • Always ask, “Where’s the test?”
    • Help make tests easier
  • 51. Be Aware!
    • You are now becoming a test expert!
    • TDD Antipatterns
    • Don’t test just to test…
  • 52. My Road To Test-Driven Development
    • Hewlett-Packard EMSO
    • Idealab
      • X1
      • Energy Innovations
  • 53. Lessons from Hewlett-Packard
    • Tests are nowhere near perfect
    • Tests can prove your point
    • Believe in tests!
  • 54. Tests are nowhere near perfect
    • 500000 lines of code
    • Hundreds of feature tests working
    • Applications run for 3 days
    • I knew it was broken
  • 55. Tests can prove your point
    • No one wanted to believe it
    • The product needed to ship
    • Wrote random component creator/messenger/destroyer
    • Core dump in less then a millisecond
    • Created tests from random iterations
    • Fixed hundreds of memory leaks and contention issues
  • 56. Lessons from X1
    • Good Test Framework
    • Keep each other honest
  • 57. Good Test Framework
    • Test::Unit
    • WWW::Mechanize
    • DBI
      • No MockObjects
  • 58. Keep each other honest
    • Test First, not test eventually
    • Everybody Writes Tests…
    • …but feel free to ask for help
  • 59. Lessons from Energy Innovations
    • Cost of Refactoring
    • Beware Gold Plating
    • It’s easy to get lazy…
  • 60. Summary
    • Learned about TDD
    • Learned about benefits (and costs) of TDD
    • Learned first steps towards TDD
  • 61. Q&A
  • 62. Bibliography
    • I would highly recommend “The Object Primer” by Scott W. Ambler, now in it’s third edition.
    • http://www.agiledata.org/essays/tdd.html
    • http://en.wikipedia.org/wiki/Test-driven_development
    • http://en.wikipedia.org/wiki/Agile_software_development
    • http://en.wikipedia.org/wiki/Continuous_integration
    • http://en.wikipedia.org/wiki/Refactoring
  • 63. Bibliography (cont)
    • http://blog.james-carr.org/?p =44
    • http://www.ipd.uka.de/Tichy/uploads/publikationen/136/MuellerHoefer2007.pdf
    • http://www.acm.org/src/subpages/gf_entries_06/DavidJanzen_src_gf06.pdf
    • http://utopia.csis.pace.edu/dps/2008/mcapellan/projects/TDD/TDD_Idea_Paper_V04-03.doc
  • 64. Bibliography (cont)
    • http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B75H1-4FC40MJ-2&_user=10&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000050221&_version=1&_urlVersion=0&_userid=10&md5=fbd92b394263506930dfafb31003a916
    • http://aegis.sourceforge.net/