Test-driven development (TDD) is a software development process that relies on the repetition of a short development cycle of requirements, design, and coding. It promotes writing tests before writing code (test-first design) and helps improve code quality by reducing defects. The TDD cycle involves writing an automated test, running the test and seeing it fail, writing the minimum amount of code to pass the test, and refactoring the code as needed. TDD brings benefits like clarifying requirements, adding executable documentation, and detecting errors early. Acceptance TDD involves automating acceptance tests to define and validate requirements. It helps establish a definition of done and improves team collaboration.

1. Test-Driven Development

2. Why? Why can’t we do the things right the first time? Why budget for correcting our own mistakes? Why don’t we commit fewer bugs into our code repository?

3. What is TDD? R elies on the repetition of a very short development cycle Promotes “Test-First Design” (TFD) Practice that supports change and refactoring S ubstantially reduces the number of defects H elps improve design, documents public interfaces, and guards against future mistakes Takes hours to learn and a lifetime to master

4. TDD development cycle Think Add a test Run all tests and see if the new one fails Write some code just to make the test pass Run the automated tests and see them succeed Refactor the code Repeat

5. TDD development cycle

6. Benefits When writing tests: Makes us clarify the acceptance criteria for the next piece of work Encourages us to write loosely coupled components Adds an executable description of what the code does (design); Adds to a complete regression suite (implementation); When running tests: Detects errors while the context is fresh in our mind (implementation); Lets us know when we’ve done enough an nothing more – promotes the “KISS” and “YAGNI” principles

7. Speed matters In TDD, you run the tests as often as one or two times every five m inute s The tests should take a reasonable time to run M ake sure your tests take under ten seconds to run A n easy way to keep your test times down is to run a subset of tests during the TDD cycle P eriodically run the whole test suite to find regressions

8. Acceptance tests Specifications for the desired behavior and functionality of a system Tell us whether the system behaves correctly from the perspective of a user. Tell us nothing about how the system implements that behavior

9. Properties of acceptance tests Owned by the customer Written together About the what not the how (about business functionality, not about software design ) Expressed in the language of the problem domain Short, precise and unambiguous

10. Example User logs in with correct data and sees a welcome message. Type word “admin” in the username field Type word “admin” in the password field Press the login button Verify that the user sees a welcome message with his name on it.

11. Acceptance TDD cycle Pick a requirement Write acceptance test Automate the acceptance test Implement the functionality using TDD

12. Acceptance TDD cycle

13. External and Internal Quality External quality is how well the system meets the needs of its customers and users Internal quality is how well it meets the needs of its developers and administrators Acceptance tests tells us about the external quality Unit tests gives us feedback about the internal quality Integration tests fall somewhere in the middle

14. The walking skeleton Before acceptance test automation build, deploy and test environment is required Deploying and testing right from the start of a project forces the team to understand how their system fits into the world A “walking skeleton” is an implementation of the thinnest possible slice of real functionality that we can automatically build, deploy, and test end-to-end It need not use the final architecture, but it should link together the main architectural components

15. Benefits of Acceptance TDD Definition of “done” Cooperative work Trust and commitment Specification by example Filling the gap

16. Summary

17. When TDD is used properly Y ou find that you spend little time debugging Although you continue to make mistakes, you find those mistakes very quickly and have little difficulty fixing them. Y ou have total confidence that the whole codebase is well-tested, which allows you to aggressively refactor at every opportunity The team communication and collaboration will be improved which leads to more happy people

18. Project chaos (stress)

19. Disadvantages of TDD Management support is essential. Without the entire organization believing that TDD is going to improve the product, management will feel that time spent writing tests is wasted . The tests themselves become part of the maintenance overhead of a project. Badly written tests are expensive to maintain . Unit tests created in a TDD environment are typically created by the developer who will also write the code that is being tested. The tests may therefore share the same blind spots with the code . The high number of passing unit tests may bring a false sense of security, resulting in less additional QA activities .

20. TDD is waste of time if Y ou aren’t disciplined . You don’t know exactly what the system should do (building the thing right vs. building the right thing). You have no plans for what need to happen . You haven’t got a clear picture of how to design the system in a loosely coupled manner . T he business model does not care about quality but rather just pushing features and out the market asap . If the code is not to be maintained. If you maintain a legacy code.

21. Useful links and resources Agile Boox - http://jamesshore.com/Agile-Book/test_driven_development.html Growing Object-Oriented Software Guided by Tests - http://www.growing-object-oriented-software.com/ Test Driven Practical TDD and Acceptance TDD for Java Developers http:// www.manning.com/koskela / Unit testing with mock objects - http://www.ibm.com/developerworks/library/j-mocktest.html Walking skeleton - http://alistair.cockburn.us/Walking+skeleton

22. Questions?