This document discusses test-driven development (TDD), a software development technique where test cases are written before implementation code. TDD involves writing a failing test case, then code to pass the test, and refactoring code as needed. Key principles are writing tests first, running tests frequently, and making code changes in small iterative steps. TDD aims to increase code quality and reduce bugs by fully testing code in short cycles.

1. TEST DRIVEN DEVELOPMENT(TDD)

2. 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

3. 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

4. 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?

5. WHY-MOTIVATION
If 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!

6. 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.

7. HOW - STAGES

8. 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

9. 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.

10. 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)

11. HOW - METHODOLOGY
Test first – Code last
You may not write production code unless you’ve first
written a failing unit test
Test more – Code more
You may not write more of a unit test than is sufficient to
fail
Test again – Code again
You may not write more production code than is
sufficient to make the failing unit test pass

12. 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

13. 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

14. HOW - TOOLS
• JUnit (Java)
• XCTest (Objective-C)
• Cpputest(C++)
• PyUnit(Python)
• ScalaTest (Scala or Java)

15. 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!

16. DISADVANTAGES
• Programmers like to code, not to test
• Test writing is time consuming
• Test completeness is difficult to judge
• TDD may not always work

17. 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.

18. 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

19. 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

20. TEST DRIVEN DEVELOPMENT(TDD)