Your SlideShare is downloading. ×
Test-Driven Development
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Test-Driven Development


Published on

TDD and acceptance TDD presentation

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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 -
    • Growing Object-Oriented Software Guided by Tests -
    • Test Driven Practical TDD and Acceptance TDD for Java Developers http:// /
    • Unit testing with mock objects -
    • Walking skeleton -
  • 22. Questions?