Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à TDD at scale - Mash Badar (UBS)
Similaire à TDD at scale - Mash Badar (UBS) (20)
Plus de jaxLondonConference
Plus de jaxLondonConference (20)
Dernier
Dernier (20)
TDD at scale - Mash Badar (UBS)
- 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 …
- 11. Aggregates that maintain their integrity … possibly use a DDD approach
- 13. A complicated set of test of fixtures … and the god of all tests
- 14. A DSL for your tests
- 15. Slow Builds
- 16. Little Overlap & Parallel Executions
- 19. Well defined level for system tests.
- 20. Inflexible code
- 21. Automated tests are Software If you write shit software you’ll write shit tests.
- 25. Look at testing holistically
- 26. The right balance of checking and testing
- 27. Moral of the Story
- 28. TDD is difficult
- 29. … that doesn’t mean we can’t do TDD!
- 30. We write good Software: Hence we do TDD.
- 31. Keep the objective in mind TDD supports the team!
- 32. Holistic approach to testing
- 33. Thanks for listening. Mashooq Badar @mashooq
Notes de l'éditeur
- 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