O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

TDD Anti-patterns (2022 edition)

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio

Confira estes a seguir

1 de 43 Anúncio

TDD Anti-patterns (2022 edition)

Test Driven Development (TDD) is a core practice in the SDLC, especially ones that run using the agile mindset and leverage the practices of eXtreme programming. Since its inception and rediscovery by Kent beck in the late 1990s, it has gained popularity among many software development teams. However, like any popular software development practices, teams lose interest in TDD overtime and drop the practice all together. The main reason behind this is practicing it "the wrong way".

In this session, I present 7 anti-patterns that can ruin the TDD experience of a software development team. I also present how to counter these anti-patterns to fully leverage the benefits of TDD.

Test Driven Development (TDD) is a core practice in the SDLC, especially ones that run using the agile mindset and leverage the practices of eXtreme programming. Since its inception and rediscovery by Kent beck in the late 1990s, it has gained popularity among many software development teams. However, like any popular software development practices, teams lose interest in TDD overtime and drop the practice all together. The main reason behind this is practicing it "the wrong way".

In this session, I present 7 anti-patterns that can ruin the TDD experience of a software development team. I also present how to counter these anti-patterns to fully leverage the benefits of TDD.

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Mais recentes (20)

Anúncio

TDD Anti-patterns (2022 edition)

  1. 1. Ahmed Misbah - September 2022 TDD Anti-patterns 2022 edition
  2. 2. TDD Anti-patterns Agenda • About the speaker • What is TDD? • The anti-patterns • References
  3. 3. TDD Anti-patterns Agenda ➡ About the speaker • What is TDD? • The anti-patterns • References
  4. 4. About the speaker Role and previous talks • Chief Software Engineer and Architect • Speaker at: ‣ Delta Technopreneurs ‣ DevOpsDays Cairo ‣ AMECSE ‣ Orange DevTest Days ‣ GDG ‣ JDC
  5. 5. About the speaker Topics of interest • DevOps • Agile and Lean • Cloud-Native Apps and beyond • Software Architecture • Java • FOSS • Arti fi cial Intelligence and ML
  6. 6. About the speaker Experience • 9 years at Orange Innovation Egypt • Delivered two award winning innovative solutions • Worked at two startups • Helped many others! • Winner of Dell Hacktrick 2022 UI/UX track • MSc. degree in ML and many other professional certi fi cations Nile University J;.lll ~l:J.. Qtertifirate (3/'~ This is to certify that Ahmed Mahmoud Amir Misbah •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Has successfully completed the program of study and fulfilled the requirements for BigData & Data Science Diploma for the period from October 2015 to July 2016 ...f:.!.l...~'!!~~!.tf....El..#.!(!.~.1.. INF Program Director ~~.__QI II C.a.::::a..;r:q;;; AU J M IW fl , : ~t '-M4' October 2016 · ····························••- •·············· Date
  7. 7. TDD Anti-patterns Agenda • About the speaker ➡ What is TDD? • The anti-patterns • References
  8. 8. Martin Fowler “Test-Driven Development (TDD) is a technique for building software that guides software development by writing tests. It was developed by Kent Beck in the late 1990's as part of Extreme Programming. In essence you follow three simple steps repeatedly: • Write a test for the next bit of functionality you want to add. • Write the functional code until the test passes. • Refactor both new and old code to make it well structured.”
  9. 9. TDD Anti-patterns Agenda • About the speaker • What is TDD? ➡ The anti-patterns • References
  10. 10. TDD Anti-patterns 7 anti-patterns 1. No test list 2. No refactoring 3. No pair/mob programming 4. No particular school 5. No integration 6. No mutation testing 7. Practice + technology before theory
  11. 11. (1) No test list
  12. 12. Kent Beck “Test-Driven Development By Example”, Chapter 25 - Test Driven Development Patterns “What should you test? Before you begin, write a list of all the tests you know you will have to write. The first part of our approach to dealing with programming stress is never to take a step forward unless we know where our foot is going to land. When we sit down to a programming session, what is it we intend to accomplish?”
  13. 13. No test list The true Red-Green-Refactor • Invented by James Shore in 2005 (link) • Steps: 1. Think: Figure out what test will best move your code towards completion. (Take as much time as you need. This is the hardest step for beginners.) 2. Red 3. Green 4. Refactor 5. Repeat
  14. 14. “The Coding Dojo Handbook”, Section 3
  15. 15. No test list How to write a test list? • Pair/mob with testers • Use test design techniques Sample test list by Kent Beck
  16. 16. (2) No refactoring
  17. 17. Martin Fowler “The most common way that I hear to screw up TDD is neglecting the third step. Refactoring the code to keep it clean is a key part of the process, otherwise you just end up with a messy aggregation of code fragments. (At least these will have tests, so it's a less painful result than most failures of design.)”
  18. 18. Refactoring What do we do in the refactor phase? • It’s when you remove duplication - Kent Beck • It’s when you sanitize the code smells - Martin Fowler • It’s when you apply patterns - Joshua Kerievsky “TDD, Where Did it All Go Wrong” video
  19. 19. Refactoring It’s all about design • “There is no design phase in TDD. Using TDD, design is inverted and distributed” • “TDD completely inverts the accepted ordering of ‘design-code-test'” • “TDD just puts the design after the test and the code. Refactoring is pure design.” “Test-Driven Development” eLearning Album - Industrial Logic Code Design Test Refactor Code Test Design/ Refactor
  20. 20. (3) No pair / mob programming
  21. 21. No pair / mob programming Issues with working solo in TDD Learning curve (technologies, recommended practices, etc.) Knowledge sharing (technologies, recommended practices, business, test list, etc.) Collective ownership (of production code and tests)
  22. 22. (4) No particular school
  23. 23. No particular school Di ff erent Architectures “Domain-speci fi c Semantic Web-based Information Systems - Any Progress?” paper
  24. 24. No particular school The schools of TDD • Classicist (aka. Chicago or Detroit school of TDD): ‣ Inside-out ‣ Tests behavior ‣ No mocks • Mockist (aka. London school of TDD) ‣ Outside-in ‣ Tests structure? ‣ Uses mocks
  25. 25. No particular school Understand the schools • A beginners explanation of the Chicago & London approaches • London vs. Chicago • Chicago TDD vs London TDD – Which one is should you use? • London vs. Chicago by Robert (Bob) Martin and Sandro Mancuso
  26. 26. (5) No integration
  27. 27. No integration Microtesting • Invented by Mike (GeePaw) Hill in 2011 (link) • The Four-Beat Cycle: 1. RED 2. GREEN 3. REFACTOR 4. INTEGRATE: We commit our changes, including the new micro-test(s), to the source vault.
  28. 28. (6) No mutation testing
  29. 29. Alex Bunardzic “Two things surprised me a lot recently: 1. Number of experienced TDDers who told me they fail to see value in Mutation testing 2. Number of experienced TDDers who told me they fail to see value in TCR”
  30. 30. No mutation testing Why Mutation Tests? • Traditional test coverage (i.e., line, statement, branch, etc.) measures only which code is executed by your tests. It does not check that your tests are able to detect faults in the executed code. It is therefore only able to identify code that is not tested • As it can detect whether each statement is meaningfully tested, mutation testing is the gold standard against which all other types of coverage are measured Source link
  31. 31. (7) Practice + technology before theory
  32. 32. Ahmed Galal - Mobile UX session - 2012 “Experience = Knowledge (i.e., Theory) + Practice”
  33. 33. Practice + technology before theory Experience, Theory and Practice • Experience is often used interchangeably with practice. • However, true experience is gained by both learning knowledge and theory and applying it (i.e., practice)
  34. 34. W. Edwards Deming - “The New Economics for Industry, Government, Education” book “Experience by itself teaches nothing... Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence, without theory, there is no learning.”
  35. 35. Practice + technology before theory Knowledge then practice + technology • Beginners start with courses that teach technologies without diving deep into the theory and recommended practices • Beginners should read: - The three laws of TDD - “Clean Code” by Robert (Bob) C. Martin - F.I.R.S.T properties - “Clean Code” by Robert (Bob) C. Martin - Test Desiderata - Kent Beck - TDD Manifesto
  36. 36. Thank you!
  37. 37. References
  38. 38. References
  39. 39. Book a free call to arrange a workshop • Introduction to TDD • Advanced topics in TDD • TDD and refactoring workshop Scan to book a free call

×