Downloaded 11 times
Uploaded byMalinda Kapuruge
Test Driven Development - a Practitioner’s Perspective
This document discusses test driven development (TDD) and provides an overview and demonstration. It begins by covering software development, testing, and TDD. It then demonstrates TDD with a NodeJS example, showing how to start with a failing test and incrementally make it pass through small changes. The benefits of TDD are outlined as better designed code, understanding requirements, quality, and confidence to refactor. Challenges with TDD for microservices and frontends are discussed. It concludes with taking questions and providing further reading suggestions.
More Related Content
Similar to Test Driven Development - a Practitioner’s Perspective
Test Driven Development - a Practitioner’s Perspective
- 1. Test Driven Development MalindaKapuruge @kaushalye Guest lecture @ Swinburne University of Technology, Melbourne a Practitioner’s Perspective 01 / 05 / 2019
- 2. Outline • Software development •Software testing • TDD • Demo • Few other topics • Questions (Interrupt me anytime)
- 3.
- 4. Users Code Development team ApplicationBusiness Features /Issues Deploy Commit Access
- 5.
- 6. Source : NIST- National Institute of Standards and Technology
- 7. Software Testing Functional Unit testing smallest testableunit Integration testing Interactions btwn modules Regression testing In-depth analysis on functionalities Smoke testing A set of test to quickly check basic functionalities ... Non-functional Load testing Stress testing Security testing Reliability testing ..,
- 8.
- 9. Unit Tests • Unitof code, e.g., a function • Smallest testable piece • Assertions • Data • Quick to run (short feedback loop) • Isolation (No connection to DBs or other services)
- 10.
- 11. TDD != Writingunit tests Application Tests Tests Application
- 12. Write a testfor something that doesn’t exist yet ?
- 13. Add test / refactor Fix Runtest Fail • Start with a failing test • Make test pass • Write more tests • Make the pass … cont. • Refactoring is part of the process • Red-green-refactor Pass
- 14.
- 15. TDD Benefits • Betterdesigned code • The interaction with other parts of code is already understood • Better understood business requirements • Tests are sort of a well-defined specification* • Improved code quality • Minimum code required to make the test pass • Confidence to refactor code • E.g., a programmer new to the team. • Evolutionary technique • Small steps towards end goal. Few lines of code at a time. • Detect bugs early • Assertions are already there • Efficient and less costly
- 16. Feedback loop isminutes. Source http://www.agilemodeling.com/essays/costOfChange.htm
- 17.
- 18. Demo time! • NodeJS– development platform • https://nodejs.org/en/download/ • Jest – Test tool • https://jestjs.io/ A function to check for strong passwords ...
- 19. What happened ? •We did NOT start with the implementation • We postponed answering the question “HOW?” • We focused on expectations • We clarified the requirements / specification • We understood the inputs and outputs • We started with the simplest form of the function, i.e., smallest step • We observed failing tests • We did small increments until the function is satisfactory • We detect bugs early in the implementation
- 20. We ended up with Agood test coverage Minimal amount of code Code satisfies current business expectations / assertions Assertions are captured as a test specification
- 21. Tools that canhelp us Test tools Development language / platform JSUnit, Jasmine, Tape, Jest, Mocha, Chai, Sinon Node Junit, Mockito, TestNG Java PyUnit, Nose, pytest Python Go test Go Rspec, Test::Unit (builtin) Ruby PHPUnit PHP Cppunit, Google test, Boost C++ * These tools are OPTIONAL. But can make it easier to write and execute tests
- 22. Practical TDD • TDDZealots – do this or you are wrong • Sometimes the first test doesn’t come naturally • Playing with code and other components/services first • Tests are good as long as all relevant assertions are covered. • ATDD • Passing tests vs Validness of solution (cheating) • Bad unit tests -> bad TDD • TDD - needs some practice • Measure test coverage
- 23.
- 24. Microservices • Is anarchitecture style • Loosely coupled services • A service represents a specific business function • Invoice service • Customer service • Payment service • Separately deployed in different runtimes • Highly maintainable, scalable and testable
- 25. runtime Microservices and TDD •Different runtimes and tech stacks • Service – service interactions • Mocks • Version control Runtime Customer Object Invoice Object runtime Customer Service Invoice Service
- 26. Microservices and TDD •Integration tests can be used to test the validity of service-service interactions • But TDD needs unit tests (short feedback loop)
- 27. Microservices and TDD •Service contracts • Pact framework • A contract testing tool • Consumer-driven • Pact tests are unit tests • TDD Pact broker Pact file ( version controlled ) Customer Service Invoice Service Unit tests Consumer Provider
- 28.
- 29.
- 30. TDD for frontend •Traditional frontend development • Modern frameworks, come with all the goodies to start TDD • e.g., react, angular, • TDD for services and models • E.g,, Enzyme • TDD for UI/Visualization ??? • Can be done… but…
- 31.
- 32. Behaviour-Driven Development • Flavorthat can be used to write unit tests • Provide a structure • Given, when, then format , e.g., Given('The user is authorised', function() {}); When('The user requests invoice data', function() {}); Then(‘Correct invoices are returned', function() {}); • Technical as well as non-technical users • TDD and BDD complements each other • Many tools, e.g., Cucumber, JBehave, RSpec.
- 33. Summary • TDD isa software development methodology • Start with failing tests, refactor until test pass. Continue… • Business requirements are captured as tests • Many benefits • Many tools • Challenges in architectures like microservices • To TDD or not to TDD? Case by case.
- 34.
- 35. Further reading • Test-DrivenDevelopment by Example – Kent Beck • http://agiledata.org/essays/tdd.html • https://www.agilealliance.org
Editor's Notes
- #2 Tesseract