• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Test Driven Development - Overview and Adoption
 

Test Driven Development - Overview and Adoption

on

  • 3,287 views

- What is TDD

- What is TDD
- TDD adoption stages
- Adopting a test strategy
- Making TDD stick

Statistics

Views

Total Views
3,287
Views on SlideShare
3,280
Embed Views
7

Actions

Likes
2
Downloads
82
Comments
1

3 Embeds 7

http://www.linkedin.com 4
http://www.pearltrees.com 2
https://www.linkedin.com 1

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

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Não consegui realizar o download, poderia me disponibilizar por e-mail?

    thinaregina@gmail.com
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Test Driven Development - Overview and Adoption Test Driven Development - Overview and Adoption Presentation Transcript

    • Test-Driven Development
    • Why Test-Driven Development (TDD)?
      • Agile implies adapting to change quickly…
      • In code, this translates to “easy to maintain & refactor” and implies…
        • Clean design
        • No duplication
        • Low/loose coupling
        • Eliminating “code smells”
        • Thorough test coverage
      • TDD is a technique that helps getting there
    • What is TDD?
      • Originates from test-first programming concepts of Extreme Programming (XP)
      • Is a software design method more than a testing method
      • Developers create automated unit tests that define code requirements before writing the code itself
    • Extreme Programming Practices Overview source: www.xprogramming.com
    • The TDD cycle
      • Add a test
      • Run all tests and see if the new one fails
      • Write code
      • Run all tests and see the new test succeed
      • Refactor the code
      Test Code Refactor source: Test-Driven Development by Example, by Kent Beck
    • TDD Key Principles
      • Write code if and only if an automated unit test fails
      • Eliminate duplication and other “ smells”
    • Benefits
      • If done well, TDD can bring tons of benefits:
      • Better test coverage
        • A safety net for refactoring
        • Helps prevent regression
        • Measurable
      • Better design
        • Developer acts as user of his own code
        • Looser coupling
        • Easier to test
        • Constant elimination of “code smells”
    • Benefits (continued)
      • Functionality required only
        • “ You Ain’t Gonna Need It” (YAGNI) principle
        • Lower maintenance cost
      • Helps managing fear in face of complexity
        • Brings confidence in the code base
        • Decreases pressure
      • Documents code
        • Lots of example usage of the code
    • Benefits (continued)
      • Improves overall quality
        • Reduces number of bugs released
        • Reduces chances of bugs reoccuring
    • TDD Adoption Stages
      • The developer starts writing unit tests around their code using a test framework like JUnit or TestNG.
      • As the body of tests increases the developer begins to enjoy a strongly increased sense of confidence in their work.
      • At some point the developer has the insight (or are shown) that writing the tests before writing the code, helps them focus on only writing the code that they need.
    • TDD Adoption Stages (continued)
      • The developer also notices that when they return to some code that they haven't seen for a while, the tests serve to document how the code works.
      • A point of revelation occurs when the developer realizes that writing tests in this way helps them to "discover" the API to their code. TDD has now become a design process.
      • Expertise in TDD begins to be drawn at the point where the developer realizes that TDD is not about testing, it is about defining behavior.
      • Behavior is about the interactions between components of the system and so the use of mocking is a fundamental to advanced TDD.
      source: www.behaviour-driven.org
    • Pitfall stopping midway
      • Too many integration tests vs unit tests
      • Tests more complex
      • Tests become constraint on change
      • Tests take much time to run
      • Tests code tightly coupled to implementation
      • A common failure mode for code bases on Agile projects
      • A solution: Use Mocks!
    • Adopting a test strategy Unit tests Integration tests Functional tests Acceptance tests + - $$
    • Another Categorization Unit tests Integration tests + - $$ Unit tests Integration tests End-to-end tests Customer tests Developer tests
    • Making TDD stick
      • Classroom training
      • Use measurement tools
      • Pair programming
      • Support from management
      • Community
      • Coding dojos
      • Reading workshops
      • Patience… it will take more time than you expect!
      • Pizza
      source: www.infoq.com, Making TDD stick, Problems and Solutions for Adopters, by Mark Levison
    • References
      • Test-Driven Development by Example ,
      • Kent Beck – Addison-Wesley, 2002
      • http://www.xprogramming.com
      • http://www.behaviour-driven.org
      • Making TDD Stick, Problems and Solutions for Adopters , Mark Levison, http://www.infoq.com, January 2009
    • Questions ?