Test-Driven Development

Why?

• Why can’t we do the things right the first time?

• Why budget for correcting our own mistakes?

• Why don’t we commit fewer bugs into our code repository?

What is TDD?• Relies on the repetition of a very short development

cycle • Promotes “Test-First Design” (TFD)• Practice that supports change and refactoring• Substantially reduces the number of defects• Helps improve design, documents public interfaces,

and guards against future mistakes• Takes hours to learn and a lifetime to master

TDD development cycle

1. Think

2. Add a test

3. Run all tests and see if the new one fails

4. Write some code just to make the test pass

5. Run the automated tests and see them succeed

6. Refactor the code

7. Repeat

TDD development cycle

BenefitsWhen writing tests:

• Makes us clarify the acceptance criteria for the next piece of work

• Encourages us to write loosely coupled components

• Adds an executable description of what the code does (design);

• Adds to a complete regression suite (implementation);

When running tests:

• Detects errors while the context is fresh in our mind (implementation);

• Lets us know when we’ve done enough an nothing more – promotes the “KISS” and “YAGNI” principles

Speed matters• In TDD, you run the tests as often as one or

two times every five minutes

• The tests should take a reasonable time to run

• Make sure your tests take under ten seconds to run

• An easy way to keep your test times down is to run a subset of tests during the TDD cycle

• Periodically run the whole test suite to find regressions

Acceptance tests

• Specifications for the desired behavior and functionality of a system

• Tell us whether the system behaves correctly from the perspective of a user.

• Tell us nothing about how the system implements that behavior

Properties of acceptance tests

• Owned by the customer

• Written together• About the what not the how (about

business functionality, not about software design )

• Expressed in the language of the problem domain

• Short, precise and unambiguous

Example

User logs in with correct data and sees a welcome message.

• Type word “admin” in the username field

• Type word “admin” in the password field

• Press the login button

• Verify that the user sees a welcome message with his name on it.

Acceptance TDD cycle

1. Pick a requirement

2. Write acceptance test

3. Automate the acceptance test

4. Implement the functionality using TDD

Acceptance TDD cycle

External and Internal Quality• External quality is how well the system meets the

needs of its customers and users• Internal quality is how well it meets the needs of

its developers and administrators

• Acceptance tests tells us about the external quality

• Unit tests gives us feedback about the internal quality

• Integration tests fall somewhere in the middle

The walking skeleton

• Before acceptance test automation build, deploy and test environment is required

• Deploying and testing right from the start of a project forces the team to understand how their system fits into the world

• A “walking skeleton” is an implementation of the thinnest possible slice of real functionality that we can automatically build, deploy, and test end-to-end

• It need not use the final architecture, but it should link together the main architectural components

Benefits of Acceptance TDD

• Definition of “done”

• Cooperative work

• Trust and commitment

• Specification by example

• Filling the gap

Summary

When TDD is used properly

• You find that you spend little time debugging

• Although you continue to make mistakes, you find those mistakes very quickly and have little difficulty fixing them.

• You have total confidence that the whole codebase is well-tested, which allows you to aggressively refactor at every opportunity

• The team communication and collaboration will be improved which leads to more happy people

Project chaos (stress)

Disadvantages of TDD• Management support is essential. Without the entire

organization believing that TDD is going to improve the product, management will feel that time spent writing tests is wasted.

• The tests themselves become part of the maintenance overhead of a project. Badly written tests are expensive to maintain.

• Unit tests created in a TDD environment are typically created by the developer who will also write the code that is being tested. The tests may therefore share the same blind spots with the code.

• The high number of passing unit tests may bring a false sense of security, resulting in less additional QA activities.

TDD is waste of time if

• You aren’t disciplined.

• You don’t know exactly what the system should do (building the thing right vs. building the right thing).

• You have no plans for what need to happen.

• You haven’t got a clear picture of how to design the system in a loosely coupled manner.

• The business model does not care about quality but rather just pushing features and out the market asap.

• If the code is not to be maintained.

• If you maintain a legacy code.

Useful links and resources

• Agile Boox - http://jamesshore.com/Agile-Book/test_driven_development.html

• Growing Object-Oriented Software Guided by Tests - http://www.growing-object-oriented-software.com/

• Test Driven Practical TDD and Acceptance TDD for Java Developers http://www.manning.com/koskela/

• Unit testing with mock objects - http://www.ibm.com/developerworks/library/j-mocktest.html

• Walking skeleton - http://alistair.cockburn.us/Walking+skeleton

Questions?