Your SlideShare is downloading. ×
0
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
TDD and Getting Paid
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

TDD and Getting Paid

5,973

Published on

Test-driven development is generally regarded as a good move: it should result in simple decoupled design, your tests tend to cover behaviour not methods, and far fewer bugs. However, just getting …

Test-driven development is generally regarded as a good move: it should result in simple decoupled design, your tests tend to cover behaviour not methods, and far fewer bugs. However, just getting unit tests in on a real, commercial project is hard - switching to TDD is even harder. Often you can start a project with good intentions and coverage, then the deadline looms and the tests go out then the hacks come in. So, instead of beating ourselves up about not being perfect let's look at an interative approach to adopting TDD principles. We'll look at tactics for selling TDD to your client, boss and colleagues. This talk will also cover methods for making TDD easier for you by showing you what tools you can use to integrate it into your development environment. In the project itself, we'll examine how we can make small but permanent steps towards full TDD, without losing that progress when deadlines hit. We'll also cover a few methods for learning on your own time and how the whole process can actually be made quite enjoyable.

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

No Downloads
Views
Total Views
5,973
On Slideshare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
56
Comments
0
Likes
5
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. Test Drivenu Development andaid! f Gettin gP Rowan MerewoodSoftware Eng. / Team Lead Ibuildings
  • 2. WHO AM I?Software Engineer &Technical Team Leadat Ibuildings UK I want to write good code and earn a living @rowan_m m
  • 3. Not ?WHO AM I?s i-am-not-a Cconsultant well-maybe-a-little
  • 4. Not ?WHO AM I?s i-am-not selling-a book
  • 5. Not ?WHO AM I?s i-am-not a-slave-to one=method
  • 6. THE GOOD @Clean code, smart devs Latest technology Building your careerElitist / Intimidating? DIFFERENT SITUATIONS
  • 7. THE BAD g Disgusting code Devs dont care Career dead-endChanges break the app. Always bug-fixing DIFFERENT SITUATIONS
  • 8. THE UGLY c Good tests are hardWriting tests takes time Time is money Youre not an expert (yet...) DIFFERENT SITUATIONS
  • 9. WHAT IS TDD?1.Decide what you want to do2.Write a test to show it working3.Run the test and watch it fail4.Write just enough code to pass the test5.Re-run the test (and test suite)6.Refactor (refine/improve)7.Re-run tests8.Repeat
  • 10. WHAT IS TDD?simplify REDH GREEN REFACTOR
  • 11. WHY IS THIS HARD?l Do you know what you want before you code it?
  • 12. WHY IS THIS HARD?l Does your client know what they want? Ever?
  • 13. Train yourself to think like a scientist1.Hypothesis2.Repeatable Experiment3.Conclusions ]
  • 14. ninja Train yourself to think like a scientist ] Kata1.Hypothesis terally: "form") ( 型 or 形 , li2.Repeatable movements A set of Experiment3.Conclusionsain and again you repeat ag ctly. un til can do it perfe Ninja weapon
  • 15. !DAVE THOMAS co-author ofThe Pragmatic Programmer Code Kata http://code kata.pragpro g.co m/
  • 16. ROY OSHEROVE - TDD Kata http://osherove.com/tdd-kata-1/ Create a simple String calculator with a method int Add(string numbers) The method can take 0, 1 or 2 numbers, and will return their sum (for an empty string it will return 0) for example “” or “1” or “1,2”
  • 17. .ROY OSHEROVE - TDD Kata demo
  • 18. Now youre an expert... warningDo not assume you canjust start to do thisin your project D
  • 19. DONT BE A HEROIntroduce tests all at once...● You will miss your deadline● Your tests will not be maintained● Your team will hate you
  • 20. DIFFERENT APPROACHES Force tests on your client Make your client want the tests L
  • 21. FORCING TESTSto your estimates.Do not compromiseyour principles. LAdd a fixed percentage
  • 22. SELLING TESTSin creating tests.Make the testsa deliverable. LUse tests to define done.Involve the client
  • 23. SELLING TESTSInvolve the clientin creating tests.Make the testsa deliverable. LUse tests to define done. Fitnesse Framework http://fitnesse.org/
  • 24. SELLING TESTSInvolve the clientin creating tests.Make the testsa deliverable. LUse tests to define done. Fitnesse Framework http://fitnesse.org/ Selenium http://seleniumhq.org/
  • 25. DONT BELIEVE THE HYPEMake sure you dont over-promise.Make sure you have theinfrastructure and skillsNO SILVER BULLETS
  • 26. v INFRASTRUCTURE1.Unit Testing2.Acceptance Testing3.Automated Deployment4.Continuous Integration5.Issue Tracking
  • 27. Unit/Acceptancprovides the tec1.Unit Testing v INFRASTRUCTURE e testing hnical base2.Acceptance Testing3.Automated Deployment4.Continuous Integration5.Issue Tracking
  • 28. Unit/ Au s v INFRASTRUCTURE e testing Acceptanc eployment ate t d tomthe d echnical base provide a quick test env.1.Unitows all Testing2.Acceptance Testing3.Automated Deployment4.Continuous Integration5.Issue Tracking
  • 29. Unit/ Au s ate t dv INFRASTRUCTURE e testing Acceptanc eployment tomthe d echnical rbasen provide ntinuouckIte Co s a qui1.Unitow makes pr s eg atio ntst env. all Testing ogress visible2.Acceptance Testing3.Automated Deployment4.Continuous Integration5.Issue Tracking
  • 30. INFRASTRUCTURE Unit/ Au s ate t d Co s a qui s v e testing Acceptanc eployment tomthe d echnical rbasen provide ntinuouckIte eg atio ntst env. ingviallows1.UnitowIssue Traress sible all Testing og ck makes pr2.Acceptance rting on TDD repo Testing3.Automated Deployment4.Continuous Integration5.Issue Tracking
  • 31. REPORTING1.Code Coverage2.Branch Coverage3.Bug Origin: - tested code - untested code4.Test/Dev Time: - per feature - per story
  • 32. REPORTING c Only trac k a metri1.Code Coverage is useful if it2.Branch Coverage urages th e and enco3.Bug Origin: behaviour ! right - tested code - untested code4.Test/Dev Time: - per feature - per story
  • 33. SKILLS & THE TEAM Owners not heroes Prepared to fail Honest & Disciplined
  • 34. TDD DOES NOTCREATE GOODa CODE Wait... What ?
  • 35. TDD DOES NOTCREATE GOOD good plana CODE good dev good code bad plan bad dev bad code
  • 36. DISASTER RECOVERY
  • 37. DISASTER RECOVERY Untestable code? Isolate and contain -or-Create a testable API
  • 38. DISASTER RECOVERY Running late? Drop features -or- Test the happy path -or- Test core only
  • 39. DISASTER RECOVERY Broken build? Fix the test -or- Delete the test (yes, delete it)
  • 40. DISASTER RECOVERY Team doesnt careUse incentives/games -or- Find another job You re worth it !
  • 41. V QUESTIONS? @rowan_m oind.i n/3191http://j thank-you

×