Uploaded byFerdous Mahmud Shaon
Getting started with Test Driven Development
Getting Started with TDD outlines the principles and process of Test-Driven Development (TDD). TDD involves writing unit tests before writing code to make the tests pass. This ensures code is testable and prevents bugs. The document demonstrates TDD by building a simple calculator, writing tests for addition and division that initially fail, then adding minimal code to pass each test. It emphasizes that TDD helps produce cleaner, more maintainable code through its focus on writing tests first and refactoring code without breaking tests. Benefits of TDD include reduced bugs, safer refactoring, and testable code, while drawbacks include potential overhead for simple projects. The document recommends resources for learning more about TDD and its
Getting started with Test Driven Development
- 1. Getting Started withTDD Ferdous Mahmud Shaon Managing Director Cefalo Bangladesh Ltd.
- 3. TDD stands for… TD D Development Driven Test
- 4. Old School DevelopmentApproach Design Development Test
- 5. New School DevelopmentApproach Design DevelopmentTest
- 6. Test Driven Development “TestDriven Development (TDD) is a technique for building software that guides software development by writing tests.” - Martin Fowler (Chief Scientist, ThoughtWorks) • TDD is NOT primarily about testing or development. • It is rather about software design, where design is evolved through testing and refactoring.
- 7. TDD starts withUnit Testing • In TDD, testing means Unit Testing • Unit Testing is a testing technique by which individual units or components of a software are tested programmatically. • Unit is the smallest testable part of any software. • In OOP, smallest unit is a method of a class. • Who is responsible for writing Unit Tests? – Testers Developers
- 8. So I needto write codes to test my code !!!??? But I learnt only writing codes, but not testing it!
- 9.
- 10. Unit Testing withJUnit • JUnit is a popular unit testing framework for Java. • Unit Tests are written like ordinary source codes. • Source codes and corresponding unit tests are kept under same package name but in different directories.
- 11.
- 12. JUnit Methods • Annotationsare used to mark a method as test method. • Some helper methods might be needed to be executed before and/or after running a test method. • All these methods must return “void” and take no parameters. • A test method must have at least one Assertion in it.
- 13. JUnit5 Assert Methods AssertMethod Description assertEquals() assertNotEquals() Invokes the equals() methods on the arguments to check whether they are equal. assertSame() assertNotSame() Uses == on the arguments to check whether they are equal assertTrue() assertFalse() Checks if the given boolean argument evaluates to true or false assertNull() assertNotNull() Checks if the given argument is null or NOT null assertArrayEquals() Checks if the given array arguments passed have same elements in the same order assertThrows() Checks if the given code block throws an Exception and the type of the Exception matches with the given type. These methods are used in unit test methods for comparing expected and actual result. They are static methods in org.junit.jupiter.api.Assertions class.
- 14. JUnit5 Annotations Annotation Description @Test Itis used to mark a method as a JUnit test. Referring to org.junit.jupiter.api.Test @BeforeEach The annotated method will be run before each test method in the test class. Referring to org.junit.jupiter.api.BeforeEach @AfterEach The annotated method will be run after each test method in the test class. Referring to org.junit.jupiter.api.AfterEach @BeforeAll The annotated method will be run before all test methods in the test class. This method must be static. Referring to org.junit.jupiter.api.BeforeAll @AfterAll The annotated method will be run after all test methods in the test class. This method must be static. Referring to org.junit.jupiter.api.AfterAll
- 15. Unit Test Examplewith JUnit5
- 16. Unit Tests BestPractices • Unit test cases should be independent. In case of any enhancements or change in requirements, unit test cases should not be affected. • Follow clear and consistent naming conventions for your unit tests. Test name should reflect the intent/purpose of the test. • In case of a change in code in any module, ensure there is a corresponding unit test case for the module, and the module passes the tests before changing the implementation. • Bugs identified during unit testing must be fixed before proceeding to the next phase in SDLC • Adopt a "test as your code" approach. The more code you write without testing, the more paths you have to check for errors.
- 17. Guidelines for writingUnit Tests A test is not a Unit Test if: – It connects with the database – It communicates across the network – It touches the file system – It can’t run at the same time as any of your other unit tests – You have to do special things to your environment (such as editing config files) to run it. — Michael Feathers, A Set Of Unit Testing Rules (2005)
- 18. Test Doubles • Unittest should test functionality in isolation. • Side effects from other classes or the system should be eliminated for a unit test, if possible. • This can be done via using test replacements (test doubles) for the real dependencies. • Test double is an object that can stand in for a real object in a test, similar to how a stunt double stands in for an actor in a movie.
- 19.
- 20. Common Excuses againstUnit Tests • I am paid to write code, not tests! • I am a developer, not tester - so I’m not responsible for writing tests! • We already have testers - why do we need unit tests? • We are working on a tight deadline - where do I have time for writing unit tests? • I don’t know how to write unit tests • Ours is legacy code - can’t write unit tests for them • If I touch the code, it may break!
- 21. Myths lead toa Vicious Cycle
- 22. "Never in thefield of software engineering has so much been owed by so many to so few lines of code.” – Martin Fowler on Unit Testing
- 23. But I alreadywrite unit tests! • Just because, you write unit tests, doesn’t mean you follow TDD! • Unit tests are often written after development (coding implementation) – That is called Plain Old Unit testing (POUting) • However in TDD approach, Unit tests must be written first before development (coding implementation)
- 24. Unit testing aftercode: Disadvantages • Testing does not give direct feedback to design and programming – But in TDD, the feedback is directly fed back into improving design and programs • Most often, after implementing the functionality in code, unit testing is omitted. – TDD inverts this sequence and ensure all components have unit tests first before implementation • Writing tests after developing code often results in “happy path” testing only!
- 25. Why Test FirstApproach?
- 26. Why Test FirstApproach?
- 27.
- 28. Step 1: Writetest that fails Red—write a little test that doesn’t work, perhaps doesn’t even compile at first! Source: Test Driven Development: By Example, Kent Beck, 240 pages, Addison-Wesley Professional, 2002
- 29. Step 2: Getcode working to pass test Green — write minimal amount of code to make the test work, committing whatever sins necessary in the process. Source: Test Driven Development: By Example, Kent Beck, 240 pages, Addison-Wesley Professional, 2002
- 30. Step 3: Cleanupand Refactor • Refactor — eliminate all duplications and code smells, which may have been introduced while getting the test to pass in Step 2. Source: Test Driven Development: By Example, Kent Beck, 240 pages, Addison-Wesley Professional, 2002
- 31.
- 32.
- 33. Let’s Build aSimple Calculator • We will try to implement a simple calculator by applying TDD approach • Let’s keep the requirements very simple. • Our simple calculator will cover only 2 functions: – Addition of 2 given numbers • Input 2 numbers • Returns the sum of the 2 numbers – Division of one number by another number • Input 2 numbers – dividend and divisor • Returns the quotient of the 2 numbers • Note, divisor cannot be zero
- 34. TDD in action SimpleCalculatorClass – Let’s start with an empty class – We’ll gradually build up this through TDD
- 35. TDD in action Test1:write a testcase for adding 2 numbers – input any 2 numbers – expect to have the sum of them
- 36. TDD in action Butour test for addition fails! Error:
- 37. TDD in action InSimpleCalculator class, we’ll write bear minimum amount of code to – fix the error by introducing add() method – Pass the test for adding 2 numbers • Change it until we make it RED to GREEN!
- 38. TDD in action Test2:write a testcase for division of 2 numbers – input 2 numbers: dividend and divisor – expect to have the quotient
- 39. TDD in action Butour test for division also fails! Error:
- 40. TDD in action InSimpleCalculator class, we’ll write bear minimum amount of code to – fix the error by introducing divide() method – Pass the test for division of 2 numbers – The goal is to pass the failing test somehow.
- 41. TDD in action Refactor •Look for any code smells, duplicates in main and test class and refactor them. • Make sure, the test result doesn’t get affected!
- 42. TDD in action Refactorthe Code Smells
- 43. TDD in action Test3:write a testcase for division with 0 as divisor – input any number as dividend and 0 as divisor – Let’s expect to have IllegalArgumentException
- 44. TDD in action Butour 0 divisor test fails! Error:
- 45. TDD in action Now,we’ll just need to throw IllegalArgumentException, if divisor is 0. This small change is enough to pass the test.
- 46. 3 Laws ofTDD Uncle Bob’s First law of Testto Dynamics: You may not write production code unless you’ve first written a failing unit test.
- 47. 3 Laws ofTDD (cont.) Uncle Bob’s Second law of Testto Dynamics: You may not write any more of a unit test than is sufficient to fail.
- 48. 3 Laws ofTDD (cont.) Uncle Bob’s Third law of Testto Dynamics: You may not write more production code than is sufficient to make the failing unit test pass.
- 49. Summarize Uncle Bob’srules for TDD • Start with a small unit test, that fails • Write bare minimum code to make the failing test pass • Refactor the code smells without affecting functionality and test result • Continue the above 3 steps until you have any failing unit tests
- 50. Benefits of TDD CleanerCode Testable SOLID Code Self-documenting Unit Tests Increased Quality, Reduced Bugs Maintainable and Extensible Code Happy-path and Unhappy path Testing Safer Refactoring Faster Debugging
- 51. When not touse TDD? • Developers must be experienced in writing tests before implementing TDD. • More suited for implementing complex business logic, back-end systems etc. • Can be overhead for very simple projects. • Not suitable for UI development. • Can backfire when the environment is not suitable or it is used incorrectly.
- 52. Does TDD guaranteeGood Code? “TDD helps with, but does not guarantee, good design & good code. Skill, talent, and expertise remain necessary.” — Esko Luontola
- 53. TDD slows downDevelopment? “I can write code a lot faster if it doesn’t have to work!” – Kent Beck
- 54. Follow the straightpath!
- 55. Recommended Reading Test DrivenDevelopment: By Example, by Kent Beck Must read on TDD by its originator Kent Beck
- 56. Recommended Reading Refactoring: Improvingthe Design of Existing Code, by Martin Fowler Covers refactoring of code smells by design principles & best practices!
- 57. Useful Links • GitHubRepository https://github.com/Cefalo/lets-learn-tdd • https://www.freecodecamp.org/news/test-driven- development-what-it-is-and-what-it-is-not-41fa6bca02a2/ • https://hackernoon.com/introduction-to-test-driven- development-tdd-61a13bc92d92 • https://www.guru99.com/test-driven-development.html • http://agiledata.org/essays/tdd.html
- 58.
- 59.