• Save
Tdd
Upcoming SlideShare
Loading in...5
×
 

Tdd

on

  • 1,033 views

Basics of Test Driven Development and its important

Basics of Test Driven Development and its important

Statistics

Views

Total Views
1,033
Views on SlideShare
1,026
Embed Views
7

Actions

Likes
1
Downloads
0
Comments
0

3 Embeds 7

http://www.lmodules.com 5
http://www.linkedin.com 1
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
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Tdd Tdd Presentation Transcript

  • TDD
    Test-Driven Development
  • Overview
    Introduction
    Extreme Programming (XP)
    Tests
    Stress and Tests
    What is Test-Driven Development?
    Misconceptions About TDD
    Motivation
    The TDD Methodology
    Benefits
    How?
    Patterns For TDD
    Vulnerabilities
    Questions
  • Introduction
    Agile methods – Group of S/W development techniques based on iterative development
    Breaking tasks into small increments with minimal planning
    Techniques such as continuous integration, automated test, pair programming, test driven development, design patterns, code refactoring and other techniques are often used to improve quality and enhance project agility
  • Extreme Programming (XP)
    • XP - Software development discipline
    • Intend to improve software quality
    • responsiveness to changing customer requirements.
    • Type of Agile Development advocating frequent releases
    • Using extreme techniques like Pair Programming, TDD, avoiding programming features until needed.
  • Tests
    We need to answer some basic strategic questions before we can talk about the details of TDD:
    What do we mean by testing?
    When do we test?
    How do we choose what logic to test?
    How do we choose what data to test?
    How do you test your software?
  • Stress and Tests
    What happens when the stress level rises?
    How do you get out of such a loop?
  • Write Test First
  • What is Test-Driven Development?
    In principle, it is just about writing the test before the program.
    But in consequence, it leads the developer to
    • first think about “how to use” the component (why do we need the component, what’s it for?)
    • and only then about “how to implement”.
    So, it’s a testing technique as well as a design technique
    • It results into components that are easy to test.
    • It results into components that are easy to enhance and adapt.
    In the end, there is no code without a test.
    The developer can tell at any time
    • whether everything still works as it should, or
    • what exactly does no longer work as it once did.
  • Misconceptions About TDD
    Creating unit tests may add time to the overall development cycle
    Time spent in UT should produce higher quality, better designed software with fewer bugs
    Implies software can be delivered faster.
    TDD makes the developer's focus too narrow and prevents the developer from seeing the big picture
    Allows constant refactor, continuous build system etc
    Doesn’t restricts upfront design when needed
  • Motivation
    If you intend to test after you‘ve developed the system, you won‘t have the time for testing.
    If things get complicated, you might fear that, the system doesn‘t work.
    If you‘re overwhelmed by the complexity, you get frustrated.
    If you don‘t have tests for the code, you shouldn‘t use it / ship it.
    If performance is only considered late, you won‘t be able to just, add a little more performance to the system.
  • The TDD Methodology
    RED - Write a test that defines how you think a small part of the software should behave. It will fail as the functionality doesn't exists at this point of time
    GREEN - Make the test run as easily and quickly as you can. Don't be concerned about the design of code, just get it to work.
    REFACTOR - Clean up the code. Now that the code is working correctly, take a step back and re-factor to remove any duplication or any other problems that were introduced to get the test to run.
  • Benefits
    The test is the executable specification.
    • You start thinking about the goal first, then about the possible implementations.
    • You understand the program‘s behavior by looking at the tests. The tests tell you more than just an API description, they show the dynamics, how to use the API.
    You develop just enough.
    • You get to the goal as quick as possible.
    • You don‘t develop unnecessary code.
    • There is no code without a test.
    • There is no test without a user requirement.
    Once you get one test working, you know it is working now and forever.
    • You use the tests as regression tests.
    The tests give us the courage to refactor.
    • You can prove that everything still works after the refactoring by simply executing the tests.
  • How?
    Don‘t start with objects (or design, or ...), start with a
    test.
    Write new code only if an automated test has failed.
    First think of the goal, the required functionality.
    Then think of the perfect interface for that operation (from the outside, black-box view).
    Run the test often – very often.
    To determine whether you‘ve reached the goal.
    To catch any bugs that have crawled back in.
    Make little steps (during coding and refactoring)
    So little that you feel comfortable with them.
    Make them larger if you feel.
    Make them smaller if you don‘t proceed with your expected
    velocity.
  • Patterns for TDD
    Testing Patterns
    Red Bar Patterns
    Green Bar Patterns
    Refactoring
  • Vulnerabilities
    I think TDD is very difficult and involves lots of discipline .
    It doesn’t prevent developers from implementing the wrong solution if they don’t understand the business problem to begin with, but it does help to ensure that the code you do write works the way you intended it to and is tested
    Difficult to use in situations where full functional tests are required to determine success or failure. Like UI, programs work with DB, specific network configuration
    Management support is essential.
    Same developer will write test cases and Actual code – test may share the same blind spots with the code
    High # of unit tests passing – can lead to less activities like Integration Testing, Devo testing etc.
  • Questions??