TDD at scale - Mash Badar (UBS)
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

TDD at scale - Mash Badar (UBS)

  • 497 views
Uploaded on

Presented at JAX London 2013 ...

Presented at JAX London 2013

Test Driven Development is a practice generally endorsed by most people. However it is also one of the most difficult to get right. I am part of a very large project where we decided to use TDD from the very start. We encountered a number of challenges and learned a lot of lessons. We are still learning and evolving our approach to TDD. We discovered that doing TDD badly is actually worse than not doing TDD at all and that it is very important to get some basics rights otherwise you'll put yourself in a world of pain.

More in: Technology , Business
  • 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
497
On Slideshare
493
From Embeds
4
Number of Embeds
1

Actions

Shares
Downloads
9
Comments
0
Likes
0

Embeds 4

https://twitter.com 4

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
  • Everyone’s doing it!Apparently : Practically shit out good quality software.
  • A couple of year ago … new project.We decided to do TDD … I mean would’ve been rude not to.Code coverage above 90%TDD key skill for hires.
  • And we’d seen the testing triangle.Outside in approach. Business Focuses Test but Run FastTake as much of the testing down towards unit level as possible.
  • Testing from a business perspectiveSo we’ll naturally write tests that are business focused.
  • We ramped up.Hired some very talented people. Kept our teams at high qualityTDD was part of our interview exercise.Most talented teams I’ve seen.
  • Then the shit hit the fan!Tests taking too long.System very difficult to change.Lots of defects in UAT … we weren’t live yet.
  • How could that happen to us?We were pretty good TDD’ers!We did everything right?
  • Remember: Written in Plain Language.Developers gravitated towards technical language.Business defined them at different levels … consequently an explosion of aggregates.
  • Well defined boundries.1 to Many -> Class to Attribute
  • The god class … Abstract TestDumping ground for fixturesMust understand to understand every test
  • Betterorganised fixtures and verificationsUses the common languageEasier to understandFlexible
  • Over 30 minutesBad Quality TestComponent tests doing too muchA lot of tests
  • Make them parallelLook for overlapPush them down to unit test level
  • Level not well understoodLeft it to developers to say if neededConcentrated too much in Component Tests
  • Actively involve the businessConstant feedback and visibilityUse it as your single place for understanding the system flows.
  • Did not represent the businessOrganised in technical componentsComponent Tests like concrete on Production code
  • Concentrate on designClean CodeSimple and Easy to understandDesign independent of technology / framework
  • Lots of defectsWe were doing TDD so why?
  • Turns out there is a log more to testing then just TDD
  • The specs should be created with involvement from business and development!
  • Software Design … Make sure that the design represent the business and is flexible where change is frequentIt’s about flexible software … your test suite must make change easier not more difficult.It’s about a holistic approach to testing … unit testing and test first is only a part of it.Know it’s limitations … some things can only be manually tested.Just because some forms of testing is difficult doesn’t mean you should leave it till the end.TDD is difficult … continuous education and practice is a must.Finally don’t do it because people say it’s a good idea – understand it’s pros and cons and see if it fits in your context.
  • Don’t do it just because people say it’s a good idea!It helps the team write software that is …Easy to understand and change
  • Quality / TDD / Design / Practice are interconnected

Transcript

  • 1. TDD at Scale Mashooq Badar @mashooq
  • 2. TDD is Cool?
  • 3. A Clean Slate … it’ll be rude not to!
  • 4. A Clean Slate: The Testing Triangle
  • 5. A Clean Slate: BDD plain text specs means we can’t get too technical!
  • 6. And then we grew … 6 teams of 7 each in two countries.
  • 7. It was all going so well … until the codebase grew.
  • 8. But we were doing TDD?
  • 9. Or did we? Lets dig in …
  • 10. Extremely complicated Component Tests
  • 11. Aggregates that maintain their integrity … possibly use a DDD approach
  • 12. A complicated set of test of fixtures … and the god of all tests
  • 13. A DSL for your tests
  • 14. Slow Builds
  • 15. Little Overlap & Parallel Executions
  • 16. http://www.datamation.com/news/tech-comics-dont-worry-its-just-a-geek-2.html
  • 17. Anemic System Tests
  • 18. Well defined level for system tests.
  • 19. Inflexible code
  • 20. Automated tests are Software If you write shit software you’ll write shit tests.
  • 21. Defects in production
  • 22. http://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/
  • 23. Look at testing holistically
  • 24. The right balance of checking and testing
  • 25. Moral of the Story
  • 26. TDD is difficult
  • 27. … that doesn’t mean we can’t do TDD!
  • 28. We write good Software: Hence we do TDD.
  • 29. Keep the objective in mind TDD supports the team!
  • 30. Holistic approach to testing
  • 31. Thanks for listening. Mashooq Badar @mashooq