Test-Driven Development


Published on

TDD and acceptance TDD presentation

Published in: Career
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Test-Driven Development

  1. 1. Test-Driven Development
  2. 2. Why? <ul><li>Why can’t we do the things right the first time? </li></ul><ul><li>Why budget for correcting our own mistakes? </li></ul><ul><li>Why don’t we commit fewer bugs into our code repository? </li></ul>
  3. 3. What is TDD? <ul><li>R elies on the repetition of a very short development cycle </li></ul><ul><li>Promotes “Test-First Design” (TFD) </li></ul><ul><li>Practice that supports change and refactoring </li></ul><ul><li>S ubstantially reduces the number of defects </li></ul><ul><li>H elps improve design, documents public interfaces, and guards against future mistakes </li></ul><ul><li>Takes hours to learn and a lifetime to master </li></ul>
  4. 4. TDD development cycle <ul><li>Think </li></ul><ul><li>Add a test </li></ul><ul><li>Run all tests and see if the new one fails </li></ul><ul><li>Write some code just to make the test pass </li></ul><ul><li>Run the automated tests and see them succeed </li></ul><ul><li>Refactor the code </li></ul><ul><li>Repeat </li></ul>
  5. 5. TDD development cycle
  6. 6. Benefits <ul><li>When writing tests: </li></ul><ul><li>Makes us clarify the acceptance criteria for the next piece of work </li></ul><ul><li>Encourages us to write loosely coupled components </li></ul><ul><li>Adds an executable description of what the code does (design); </li></ul><ul><li>Adds to a complete regression suite (implementation); </li></ul><ul><li>When running tests: </li></ul><ul><li>Detects errors while the context is fresh in our mind (implementation); </li></ul><ul><li>Lets us know when we’ve done enough an nothing more – promotes the “KISS” and “YAGNI” principles </li></ul>
  7. 7. Speed matters <ul><li>In TDD, you run the tests as often as one or two times every five m inute s </li></ul><ul><li>The tests should take a reasonable time to run </li></ul><ul><li>M ake sure your tests take under ten seconds to run </li></ul><ul><li>A n easy way to keep your test times down is to run a subset of tests during the TDD cycle </li></ul><ul><li>P eriodically run the whole test suite to find regressions </li></ul>
  8. 8. Acceptance tests <ul><li>Specifications for the desired behavior and functionality of a system </li></ul><ul><li>Tell us whether the system behaves correctly from the perspective of a user. </li></ul><ul><li>Tell us nothing about how the system implements that behavior </li></ul>
  9. 9. Properties of acceptance tests <ul><li>Owned by the customer </li></ul><ul><li>Written together </li></ul><ul><li>About the what not the how (about business functionality, not about software design ) </li></ul><ul><li>Expressed in the language of the problem domain </li></ul><ul><li>Short, precise and unambiguous </li></ul>
  10. 10. Example <ul><li>User logs in with correct data and sees a welcome message. </li></ul><ul><li>Type word “admin” in the username field </li></ul><ul><li>Type word “admin” in the password field </li></ul><ul><li>Press the login button </li></ul><ul><li>Verify that the user sees a welcome message with his name on it. </li></ul>
  11. 11. Acceptance TDD cycle <ul><li>Pick a requirement </li></ul><ul><li>Write acceptance test </li></ul><ul><li>Automate the acceptance test </li></ul><ul><li>Implement the functionality using TDD </li></ul>
  12. 12. Acceptance TDD cycle
  13. 13. External and Internal Quality <ul><li>External quality is how well the system meets the needs of its customers and users </li></ul><ul><li>Internal quality is how well it meets the needs of its developers and administrators </li></ul><ul><li>Acceptance tests tells us about the external quality </li></ul><ul><li>Unit tests gives us feedback about the internal quality </li></ul><ul><li>Integration tests fall somewhere in the middle </li></ul>
  14. 14. The walking skeleton <ul><li>Before acceptance test automation build, deploy and test environment is required </li></ul><ul><li>Deploying and testing right from the start of a project forces the team to understand how their system fits into the world </li></ul><ul><li>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 </li></ul><ul><li>It need not use the final architecture, but it should link together the main architectural components </li></ul>
  15. 15. Benefits of Acceptance TDD <ul><li>Definition of “done” </li></ul><ul><li>Cooperative work </li></ul><ul><li>Trust and commitment </li></ul><ul><li>Specification by example </li></ul><ul><li>Filling the gap </li></ul>
  16. 16. Summary
  17. 17. When TDD is used properly <ul><li>Y ou find that you spend little time debugging </li></ul><ul><li>Although you continue to make mistakes, you find those mistakes very quickly and have little difficulty fixing them. </li></ul><ul><li>Y ou have total confidence that the whole codebase is well-tested, which allows you to aggressively refactor at every opportunity </li></ul><ul><li>The team communication and collaboration will be improved which leads to more happy people </li></ul>
  18. 18. Project chaos (stress)
  19. 19. Disadvantages of TDD <ul><li>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 . </li></ul><ul><li>The tests themselves become part of the maintenance overhead of a project. Badly written tests are expensive to maintain . </li></ul><ul><li>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 . </li></ul><ul><li>The high number of passing unit tests may bring a false sense of security, resulting in less additional QA activities . </li></ul>
  20. 20. TDD is waste of time if <ul><li>Y ou aren’t disciplined . </li></ul><ul><li>You don’t know exactly what the system should do (building the thing right vs. building the right thing). </li></ul><ul><li>You have no plans for what need to happen . </li></ul><ul><li>You haven’t got a clear picture of how to design the system in a loosely coupled manner . </li></ul><ul><li>T he business model does not care about quality but rather just pushing features and out the market asap . </li></ul><ul><li>If the code is not to be maintained. </li></ul><ul><li>If you maintain a legacy code. </li></ul>
  21. 21. Useful links and resources <ul><li>Agile Boox - http://jamesshore.com/Agile-Book/test_driven_development.html </li></ul><ul><li>Growing Object-Oriented Software Guided by Tests - http://www.growing-object-oriented-software.com/ </li></ul><ul><li>Test Driven Practical TDD and Acceptance TDD for Java Developers http:// www.manning.com/koskela / </li></ul><ul><li>Unit testing with mock objects - http://www.ibm.com/developerworks/library/j-mocktest.html </li></ul><ul><li>Walking skeleton - http://alistair.cockburn.us/Walking+skeleton </li></ul>
  22. 22. Questions?