TDD and Getting Paid
Upcoming SlideShare
Loading in...5
×
 

TDD and Getting Paid

on

  • 5,307 views

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.

Statistics

Views

Total Views
5,307
Views on SlideShare
2,949
Embed Views
2,358

Actions

Likes
3
Downloads
55
Comments
0

18 Embeds 2,358

http://merewood.org 2209
http://protalk.ldev 54
http://protalk.me 29
http://www.merewood.org 20
http://abtasty.com 12
http://protalk.localhost 11
http://mlocal.merewood.org 5
http://dev.protalk.nl 3
http://merewood.org:6081 3
http://www.php-talks.com 2
http://m.merewood.org 2
http://translate.googleusercontent.com 2
http://webcache.googleusercontent.com 1
http://33.33.33.10 1
http://mrowan8832.merewood.org.moovapp.com 1
http://www.365dailyjournal.com 1
http://www.linkedin.com 1
http://ranksit.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

TDD and Getting Paid TDD and Getting Paid Presentation Transcript

  • Test Drivenu Development andaid! f Gettin gP Rowan MerewoodSoftware Eng. / Team Lead Ibuildings
  • WHO AM I?Software Engineer &Technical Team Leadat Ibuildings UK I want to write good code and earn a living @rowan_m m
  • Not ?WHO AM I?s i-am-not-a Cconsultant well-maybe-a-little
  • Not ?WHO AM I?s i-am-not selling-a book
  • Not ?WHO AM I?s i-am-not a-slave-to one=method
  • THE GOOD @Clean code, smart devs Latest technology Building your careerElitist / Intimidating? DIFFERENT SITUATIONS
  • THE BAD g Disgusting code Devs dont care Career dead-endChanges break the app. Always bug-fixing DIFFERENT SITUATIONS
  • THE UGLY c Good tests are hardWriting tests takes time Time is money Youre not an expert (yet...) DIFFERENT SITUATIONS
  • 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
  • WHAT IS TDD?simplify REDH GREEN REFACTOR
  • WHY IS THIS HARD?l Do you know what you want before you code it?
  • WHY IS THIS HARD?l Does your client know what they want? Ever?
  • Train yourself to think like a scientist1.Hypothesis2.Repeatable Experiment3.Conclusions ]
  • 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
  • !DAVE THOMAS co-author ofThe Pragmatic Programmer Code Kata http://code kata.pragpro g.co m/
  • 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”
  • .ROY OSHEROVE - TDD Kata demo
  • Now youre an expert... warningDo not assume you canjust start to do thisin your project D
  • DONT BE A HEROIntroduce tests all at once...● You will miss your deadline● Your tests will not be maintained● Your team will hate you
  • DIFFERENT APPROACHES Force tests on your client Make your client want the tests L
  • FORCING TESTSto your estimates.Do not compromiseyour principles. LAdd a fixed percentage
  • SELLING TESTSin creating tests.Make the testsa deliverable. LUse tests to define done.Involve the client
  • SELLING TESTSInvolve the clientin creating tests.Make the testsa deliverable. LUse tests to define done. Fitnesse Framework http://fitnesse.org/
  • SELLING TESTSInvolve the clientin creating tests.Make the testsa deliverable. LUse tests to define done. Fitnesse Framework http://fitnesse.org/ Selenium http://seleniumhq.org/
  • DONT BELIEVE THE HYPEMake sure you dont over-promise.Make sure you have theinfrastructure and skillsNO SILVER BULLETS
  • v INFRASTRUCTURE1.Unit Testing2.Acceptance Testing3.Automated Deployment4.Continuous Integration5.Issue Tracking
  • Unit/Acceptancprovides the tec1.Unit Testing v INFRASTRUCTURE e testing hnical base2.Acceptance Testing3.Automated Deployment4.Continuous Integration5.Issue Tracking
  • 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
  • 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
  • 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
  • REPORTING1.Code Coverage2.Branch Coverage3.Bug Origin: - tested code - untested code4.Test/Dev Time: - per feature - per story
  • 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
  • SKILLS & THE TEAM Owners not heroes Prepared to fail Honest & Disciplined
  • TDD DOES NOTCREATE GOODa CODE Wait... What ?
  • TDD DOES NOTCREATE GOOD good plana CODE good dev good code bad plan bad dev bad code
  • DISASTER RECOVERY
  • DISASTER RECOVERY Untestable code? Isolate and contain -or-Create a testable API
  • DISASTER RECOVERY Running late? Drop features -or- Test the happy path -or- Test core only
  • DISASTER RECOVERY Broken build? Fix the test -or- Delete the test (yes, delete it)
  • DISASTER RECOVERY Team doesnt careUse incentives/games -or- Find another job You re worth it !
  • V QUESTIONS? @rowan_m oind.i n/3191http://j thank-you