Test Driven Development
-
Upload
chowdhury343 -
Category
Education
-
view
29 -
download
0
Transcript of Test Driven Development
OUTLINE
1. What
Introduction
What is TDD
2. Why
Motivation
Why TDD
3. How
Stages
Colors
Principles
Methodology
Best practices
Tools
4. Summary
Advantages
Disadvantages
Conclusions
5. References
INTRODUCTION
• Test-Driven Development (TDD) is a software development technique
that involves repeatedly first writing a test case and then implementing
only the code necessary to pass the test
• The technique began to receive publicity in the early 2000s as an aspect
of Extreme Programming
• A method of designing software, not merely a method of testing
WHAT IS TDD?
TDD is a technique whereby you write your test cases before you write any implementation code
Forces developers to think in terms of implementer and user
Tests drive or dictate the code that is developed
“Do the simplest thing that could possibly work”
Developers have less choice in what they write
An indication of “intent”
Tests provide a specification of “what” a piece of code actually does – it goes some way to defining an
interface
Some might argue that “tests are part of the documentation”
Could your customers/clients write tests?
WHY-MOTIVATIONIf you intend to test after you‘ve developed the system, you won‘t have the time for testing.
->Write the tests before the code!
If things get complicated, you might fear that “the system“ doesn‘t work.
->Execute the tests and get positive feedback (everything still works) or get pointed to the
bit that does not / no longer work.
If you‘re overwhelmed by the complexity, you get frustrated.
->Start with the simplest thing and proceed in tiny steps!
If you don‘t have tests for the code, you shouldn‘t use it / ship it.
->This can‘t happen if you write the test first (so you reach better test coverage than with
functional tests).
If performance is only considered late, you won‘t be able to just “add a little more
performance“ to the system.
->Re-use unit tests for performance tests even during development and don‘t start with
performance tests late in the project!
WHY TDD?
• “If you don’t have tests, how do you know your code is doing the
thing right and doing the right thing?
• Many projects fail because they lack a good testing methodology.
• It’s common sense, but it isn’t common practice.
• The sense of continuous reliability and success gives you a feeling
of confidence in your code, which makes programming more fun.
HOW - STAGES
1. Add a test
2. Run all tests and see if the new one fails
3. Write some code
4. Run tests
5. Refactor code
6. Repeat
HOW - COLORS
Red
Write a little test that doesn‘t work (and perhaps doesn‘t even
compile at first).
Green
Make the test work quickly (committing whatever sins
necessary)
Refactor
Eliminate all of the duplication created in merely getting the test
to work, improve the design.
HOW - PRINCIPLES
• Look from usage point of view - Don‘t start with objects (or design, or
...), start with a test.
• Failed test – good test
• First think of the goal, the required functionality.
• 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(you can customize size if you want)
HOW - METHODOLOGY
Test first – Code lastYou may not write production code unless you’ve first
written a failing unit test
Test more – Code moreYou may not write more of a unit test than is sufficient to
fail
Test again – Code againYou may not write more production code than is
sufficient to make the failing unit test pass
HOW – BEST PRACTICES
• Use special functions for setup and
finitialization of test cases(teardown, etc.)
• Use timeouts
• Maintain test code the same as production code
• Review your tests with team
HOW – AVOID
• Tests that depend on system state that was
manipulated from previous test cases
• Dependences between test cases
• Exact timing or performance
• Slow tests
HOW - TOOLS
• JUnit (Java)
• XCTest (Objective-C)
• Cpputest(C++)
• PyUnit(Python)
• ScalaTest (Scala or Java)
ADVANTAGES
For developers:
Much less debug time
Code proven to meet requirements
Tests become Safety Net
Eliminate Bug Pong
Rhythm of Success
For business:
Shorter development cycles
Near zero defects
Tests become an asset
Tests are documentation
Competitive advantage!
DISADVANTAGES
• Programmers like to code, not to test
• Test writing is time consuming
• Test completeness is difficult to judge
• TDD may not always work
CONCLUSIONS• TDD produces 100% tested/testable code
Ideally, no code should go into production unless it has associated tests
Catch bugs before they are shipped to your customer
Often referred to as “No code without tests”
• Tests determine, or dictate, the code, they are driven by requirements
• TDD let you use tests as
A validation tool
A documentation tool
A design tool
• Increases development speed, because less time is spent chasing bugs.
• Improves code quality because of the increased modularity, and continuous and relentless refactoring.
• Decreases maintenance costs because the code is easier to follow.
CONCLUSIONS• More code has to be written using TDD but that is not a problem in Software Development
• TDD does not replace traditional testing
It defines a proven way that ensures effective unit testing
Tests are working examples of how to invoke a piece of code
Essentially provides a working specification for the code
• Techniques have to be learned by developers and enforced by managers
• User Interface testing is the hardest
• No application code is written without writing a failing test first.
• It’s all about early problem identification, early find, early fix, reduced cost
REFERENCES
http://en.wikipedia.org/wiki/Test-driven_development
http://msdn.microsoft.com/en-
us/library/aa730844(v=vs.80).aspx
http://www.slideshare.net/progmania1/tdd-class-1
https://developer.apple.com/library/ios/documentation/Devel
operTools/Conceptual/testing_with_xcode/Introduction/In
troduction.html#//apple_ref/doc/uid/TP40014132-CH1-
SW1