Test-Driven Development
Upcoming SlideShare
Loading in...5
×
 

Test-Driven Development

on

  • 521 views

TDD and acceptance TDD presentation

TDD and acceptance TDD presentation

Statistics

Views

Total Views
521
Views on SlideShare
521
Embed Views
0

Actions

Likes
1
Downloads
14
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Test-Driven Development Test-Driven Development Presentation Transcript

  • Test-Driven Development
  • 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?
  • 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
  • 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
  • TDD development cycle
  • 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
  • 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
  • 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
  • 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
  • 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.
  • Acceptance TDD cycle
    • Pick a requirement
    • Write acceptance test
    • Automate the acceptance test
    • Implement the functionality using TDD
  • Acceptance TDD cycle
  • 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
  • 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
  • Benefits of Acceptance TDD
    • Definition of “done”
    • Cooperative work
    • Trust and commitment
    • Specification by example
    • Filling the gap
  • Summary
  • 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
  • Project chaos (stress)
  • 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 .
  • 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.
  • 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
  • Questions?