TDD - Seriously, try it! - Opensouthcode
Download as PPTX, PDF
0 likes38 views
TDD involves writing tests before code to help design and develop software incrementally. It can find defects earlier and make software easier to maintain with fewer bugs. While difficult to learn, TDD seeks to build better modular code through a simple iterative process. Starting small with katas and practicing regularly, including pair programming, can help adapt to TDD's mechanics. Though challenges exist, it is worth trying TDD to potentially improve software quality and reduce costs over time.
TDD - Seriously, try it! - Opensouthcode
- 1. TDD: seriously, try it ! June 23
- 3. Review the basics around TDD Understand the benefits of writing code designed by tests VS building the tests after we write our code (I hope) learn some tips See a { live coding } example so do not run away, please! Why this session?
- 5. 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 Barcelona Developers Conference ( DevBcn ), former JBCNConf Java Champion Father, former mountain marathon runner Who am I?
- 6. 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
- 7. 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
- 8. ... follow a simple process 鏝 that helps you to design & develop your software in a straightforward and incremental 誌 way ( 鏝 feedback loop ) find defects earlier 槽 (when running or designing your tests) easily detect regression errors make your software easier to With TDD, you can...
- 9. ... your tests will guide 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) - Guest Editors' Introduction: TDD--The Art of Fearless also with TDD
- 10. 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
- 11. 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
- 13. You learned how to write code time ago, and now youd may learn a different way of writing software. Like learning to ride a very different bike,... but being So, how it is?
- 14. To be used in your design & coding process , for building better modularized and tested software And, what does it seek?
- 15. The process
- 16. 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, ... But, how to start?
- 17. 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
- 18. 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
- 19. 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
- 20. 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
- 21. 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 dont need to get into details on any test to understand what are they pursuing The result will be focused on the business
- 22. 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
- 23. 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
- 33. 槽
- 46. 槽 槽
- 55. TDD helps you to design & develop your code in a simple and effective way (iterative, faster & 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
- #7: Take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output.
- #9: VS create tests after
- #10: 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
- #12: - Forget : especially if you are not in an environment / team that does not encourage its use or you cannot experiment with it comfortably - Having a high level of coverage is an indirect consequence of using/applying TDD
- #16: 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
- #18: -> 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.
- #19: 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
- #22: -> min 8 !!!
- #23: Nacho -
- #24: Genre = spoke yonra -> min 13'
- #40: We have to run the test! -> we have not instantiated the repository
- #41: We dont want to call the DB in a unit test!
- #43: >>> MOCKED the repository !!!!
- #44: Test pass
- #45: Lets build the repository
- #48: Include deps
- #49: And the structure!
- #50: And the structure!
- #51: Built the implementation
- #52: Run the tests!
- #53: toString + equals + hashcode in Film