TEST DRIVEN DEVELOPMENT(TDD)

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

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

TEST DRIVEN DEVELOPMENT(TDD)