TDD at scale - Mash Badar (UBS)


Published on

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.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

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
  • TDD at scale - Mash Badar (UBS)

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