TDD - Seriously, try it! (updated '22)
Download as PPTX, PDF0 likes34 views
The document discusses Test-Driven Development (TDD), its origins, benefits, and challenges, as well as tips for effectively implementing it. TDD encourages designing software with testing in mind, which can lead to fewer bugs and easier maintenance, but also poses a high learning curve and requires significant effort. The author, Nacho Cougil, emphasizes the importance of practice and collaboration in mastering TDD techniques.
TDD - Seriously, try it! (updated '22)
- 1. TDD: seriously, try it ! 😃 JDD 2022
- 3. • Review the basics around TDD • Understand the benefits of building code designed by tests VS building the tests after we write our code • See an example • (I hope) learn some tips • … so do not run away, please! 😉 Why this session?
- 4. Nacho Cougil • Principal Software Engineer at Dynatrace • TDD & clean code fan • Started to write in Java before Y2K • Founder of the Barcelona Java Users Group ( BarcelonaJUG ) & co- founder of the Java and JVM Barcelona Conference ( JBCNConf DevBcn ) • Father, former mountain marathon runner 😅 • @icougil Who am I?
- 6. • Where it cames from? • Advantages & disadvantages • Process • Good habits • Example • Final Recap Agenda
- 7. • Where it cames from? • Advantages & disadvantages • Process • Good habits • Example • Final Recap Agenda
- 8. Kent Beck “rediscovered” TDD when writing first testing framework SUnit in 1994. TDD became part of eXtreme Programming (XP) book in 2000. Developed XP during his work at Chrysler The book Test-Driven Development by Example was published in 2002 A bit of history
- 9. Mockist (London) • Entry point: acceptance test • Design from top down • Main focus on the interactions between the components of our solution • Focus on messages we will use with our classes. Here is where mock objects appear Classical (Chicago) • Described by Kent Beck • More emphasis on “discovering” the internals of our code mainly by refactoring • The structure of our classes and modules emerges as we evolve our code (ex: removing duplication, encapsulation, etc) • Focused on changes in an state or return values from functions Two TDD schools
- 11. … you follow a simple process ⚙️ that helps you to design and develop your software in a straightforward way … you can find defects earlier ⏱ (when running or designing your tests) … you can easily detect regression errors 🔴 … your software is going to be easier to refactor because of a safety net ✅ Imagine…
- 12. ... your software guides you how a consumer will use your component ⏛ … tests are living documentation (really 🖖 !!) … the software you write it is likely to have less bugs 🐛 … your development costs 💰 will be lower References: - Test-driven development as a defect-reduction practice (IEEE) Imagine…
- 13. It is not so easy to start with 😅 (not many good places to help, majority of people are not using it daily) Has a high learning curve 😟 (depends directly on the complexity of your code + your design and engineering capabilities) Can be a large investment 💸 in a team (depending on the experience of the members + requires time ⏳ & effort 🙇♀️🙇♂️) Yes, TDD has some disadvantages
- 14. It is really easy to forget 😓 about it It provokes resistance ☹️ (in some people ⚔️) Can be corrupted and lead to the syndrome of reaching the highest possible level of coverage 🙈 It is extremely difficult 😤 to master at it Yes, TDD has some disadvantages
- 16. You learned how to write code time ago,… …and now you’d may learn a different way of writing software. Like “learning to ride a very different bike”,... but being So, … how it is?
- 17. To be used in your design & coding process , for building better modularized and tested software And, what does it seek?
- 18. • Where it cames from? • Advantages & disadvantages • Process • Good habits • Example • Final Recap Agenda
- 19. The process
- 20. • Where it cames from? • Advantages & disadvantages • Process • Good habits • Example • Final Recap Agenda
- 21. Start little by little: katas, POCs, personal projects, ... Practice... • ... and keep practicing • ... and keep on • ... until you finally internalise it 🖖♀️😉 Practice with somebody else ( pair-programming ) Keep learning: online content, books, ... Learn and practice
- 22. An Extreme Programming (XP) Practice in which 2 developers participate in one development effort at one workstation. One, the driver, writes code while the other, the navigator or observer, reviews the code as it is typed in. The 2 engineers switch roles frequently. While reviewing, the observer also considers the "strategic" direction of the work, coming up with ideas for Pair programming
- 23. Martin Fowler (concepts) • https://www.martinfowler.com/bliki/TestDouble.html • https://martinfowler.com/articles/mocksArentStubs.h tml • https://martinfowler.com/articles/practical-test- pyramid.html Dave Farley (CI, TDD, etc) • https://www.youtube.com/ContinuousDelivery/ James Shore (TDD series) • https://www.youtube.com/jdlshore/ Jason Gorman (Java Code Craft) • https://www.youtube.com/parlezuml/ Recommended content
- 24. Before you write production code, check 👀 that your test is failing 🔴 Each test has only 1 reason to fail Write the assertion first Technical good habits
- 25. Tests naming convention Describe the expected behaviour, not the internals. Our tests should describe behaviour in plain english Ending the class name with Should will “force “ you to start describing an action for every test you may create
- 26. Our tests methods will only describe behavior. Therefore, we will have a better understanding on what this class does Our tests will be more clear If some tests fails, we can have a look and see easily which case is failing We don’t need to get into details on any test to understand what are they pursuing The result will be focused on the business
- 27. Test creation order 1) Name the class 2) Name the method 3) Define what you want to check 4) Trigger the code 5) Do the setup
- 28. • Where it cames from? • Advantages & disadvantages • Process • Good habits • Example • Final Recap Agenda
- 29. Warning – Live coding!
- 30. Requirements: • Build a service that returns a list of films that are associated with a particular genre • By default, the result must be ordered according to the average rating given to the films by the users • A film should contain at least an id, title a year when it was published, one or more tags and one or more genres Example: recommendationService.filmsByGenre(”science- fiction”) https://github.com/icougil/FilmRecommendationService We have just started working in a startup that sells and rents out films over the Internet Our product managers have told us that they want to add new functionalities by building a service that allows them to recommend films to the users of the current platform. Kata: Film Recommendation Service
- 31. • Where it cames from? • Advantages & disadvantages • Process • Good habits • Example • Final Recap Agenda
- 32. • TDD helps you to design & develop your code in a simple and effective way (better modular design) 👌 • It is difficult to adapt to its mechanics and sometimes is difficult 😅 to maintain its practice... • It worth a try 😉 (your software will have less bugs 🐛 & it will be easier to maintain 💰) • There are some tips 💡 ( could make your life easier ) • Try to pair, it will help 😃 you ( a lot ) • Practice, practice & practice 🖖 again Final Recap
Editor's Notes
- #9: “Take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output.”
- #12: VS create tests after…
- #13: IEEE = ai triple i IEEE: case study at IBM 2003 – 40% fewer defects when using TDD The art of fearless: increased effort and/or quality effect (from IEEE) -- good collection of articles and empirical studies on TDD both in private companies and in the academic world
- #15: - Fotget : especially if you are not in an environment / team that does not encourage its use or you cannot experiment with it comfortably
- #20: Specify what you want to code to do Create just enough code to satisfy the desired behaviour (just make it work!) Clean your code and test / remove duplication / make it better
- #23: -> min 10-11' This back-and-forth between test and code, driver and navigator, can offer better/richer feedback when building a system. This is intended to free the driver to focus all of their attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.
- #24: GOOST >> TDD learn, understand & apply TDD by example – basic intro, idealised situation… The art of unit testing – easy to read TDD a practical guide – some examples with GUI & real examples
- #27: -> min 8 !!!
- #28: Nacho -
- #30: -> min 12'
- #31: Genre = spoke “yonra” -> min 13'