Test Driven Development

1. Introduction

2. Traditional development

developpement traditionnel

3. Test-driven development

tdd 1

4. Test-driven development

tdd 2

5. Test-driven development

tdd 3

6. Test-driven development

tdd 4

7. Approach

  1. Write test cases before the software unit

    • Test cases describe what the unit should do

    • Before writing the code, tests fail

  2. Implement the code that makes the test case pass

    • After the implementation, test cases should pass

8. Development Style

TDD Mantra : red/green/refactor

  1. Write tests and make them fail

  2. Write code to make tests pass

  3. Refactor

Style, comme KISS (Keep it simple, stupid) ou YAGNI (You Ain't Gonna Need It).

9. Consequences

  • Test cases specify what the unit should do, but not how.

Test cases specify what the program should do, not how it should do it. TDD must be associated with frequent refactoring review code structure don’t forget design. Great importance of non-regression testing when refactoring test cases that passed must continue to pass

  • First, developers think about how to use the unit.

  • Second, they think about how to implement it.

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.

It is a development approach that results into units that are easy to:

  • Unit test

  • Enhance and adapt

So, it is 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.

Developers know at any time:

  • What works as it should

  • What does no longer work as it once did

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.

10. Motivations

  • Developers never have free time to write tests

  • Tests help developers to overcome complexity.

    • Reduces developer’s frustration

If you intend to test after you have developed the system, you will not 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 are overwhelmed by the complexity, you get frustrated. "Start with the simplest thing and proceed in tiny steps!

11. TDD and unit tests

12. Development Cycle

Five steps cycle:

  1. Write a unit test

  2. Make it fail

  3. Write enough code to make it pass

  4. Check that the test passes

  5. Eliminate duplicate code, improve design

check that it fails (because the code it’s testing doesn’t exist), to verify that the test is valid;

13. Benefits

Test cases become a support to documentation:

  • They specify the expected behavior

  • They show examples of code usage

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.

YAGNI (You Ain’t Gonna Need It).

  • Developers only write necessary code

    • They only code when a test fails

  • No code without test and no test without a user requirement

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. It‘s more fun that way, it reduces fear.

There’s no code without testing: so there’s no structural testing, and it’s not easy to use a code interface that doesn’t exist, so we have functional tests at the system test level.

  • Rapid feedback on code quality

  • Short development cycle iterations

  • Code is executed straight away

14. Benefits

Automatic unit tests are reproducible:

  • They can be used as non-regression tests and after refactoring.

  • They reduce fear on changes

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. It is more fun that way, it reduces fear.

15. Development Strategy

16. Development Strategy

  1. Test often

    • to find errors quickly

    • to know when it is finished

  2. Move forward by small steps

    • programming and refactoring

  3. Use automation tools.

17. Development Strategy

tdd 5

18. Debugging Strategy

19. Debugging Strategy

  • Repeat:

    1. Find the most annoying defect

    2. Write a unit test that exposes it

    3. Correct the error

    4. Test

    5. Refactor

    6. Test again

20. Debugging Strategy

debug

21. Maintenance

22. Maintenance

Legacy code:

— Does someone remember who wrote this code?

— Last time someone touched this, we needed 3 weeks to make it work again.

— The documentation is available, but it does not correspond to the code anymore.

Legacy code = code patrimonial

23. Working with legacy code

  • Developers must take small steps, like a tightrope walker

  • Without forgetting the safety network:

    • Unit tests, versioning, backups

Go Hunting for BearBuild the Safety NetWork in small incrementsExpect to slow down, then speed upMeasure the results

24. Maintenance approach

legacy

25. Maintenance approach

  1. Try to understand the legacy code. And don’t.

  2. Try to write a unit test based on what they understood. The test fails.

  3. Improve the test until it passes

  4. Restart with the next unit.

Write a test to see if you understand :Test FAILS Adapt test (iteratively): Test PASSES Move on to next piece.

26. Conclusion

27. Conclusion

  • Requirements drive the tests.

  • Tests drive the development of the application code.

  • No application code is written without writing a failing test first.

  • Tests are executed often.

  • Tests and code are written in elementary increments.

  • Refactoring becomes a continuous operation and is supported by a passing a suite of tests.

Tests are collected in a suite and the suite is run frequently, like every time after code is written.Test and code are written in elementary increments.Refactoring is a continuous operation, and is supported by a passing battery of tests.

28. Benefits

  • Reduces debugging time (and bugs)

  • Short development cycles

  • Tests become part of the software product

  • Improve documentation

  • Improve code quality

  • Reduce maintenance costs

  • Increases development speed (less time is spent chasing bugs)

Reduces the number of bugs by orders of magnitude, 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.