Dennis van der Stelt

Introduction in the TDD Mantra
Session Code: NE.17
Introduction
• Class-A
–
–
–
–

Kennisprovider
Microsoft development
Training / Coaching
www.class-a.nl

• Dennis van der Stelt
– Trainer / Coach
– Weblog at http://bloggingabout.net/blogs/dennis/
Agenda
•
•
•
•
•
•
•
•

A quick introduction into unit testing
Test Driven Development mantra
Refactoring
Benefits of Test Driven Development
Demo
Key rules of Test Driven Development
Mocking / Stubbing
Legacy code
A quick introduction
Unit testing
1. Automated testing
2. Facilitates change
3. Simplifies integration
4. Documentation
unit testing isn’t about just testing code
it‘s about allowing you to
determine when behavior changes
TDD Mantra
RED

GREEN
I’M TEST-DRIVEN

•
•
•
•

Write the test
Write the code
Refactor
Repeat

REFACTOR
TDD Mantra
Where to begin?
• Work from specification (or notes, or napkin)
• Create a list of tests
• Pick the simplest one
• Make test, make code
• Refactor

• Find a bug? Create the test that would’ve
caught it!
Test Driven Development
...is not about testing.
• It’s about design
• It’s about unambigious requirements
• It’s also about simplicity and YAGNI
Simplicity is more complicated then you think. But it’s well worth it.
Ron Jeffries, Extreme Programming Installed, 2001
Test Driven Development
...is about simple design that
1.
2.
3.
4.

Runs all tests
Reveals all intention
Has no duplication
Has the fewest number of classes and methods
Test Driven Development
“The act of writing a unit test is more an act of design then of verification”

- Robert C. Martin
“Test-driven development seeks specification, not validation, letting you think
through your design before you write your functional code”

- Scott Ambler
“Test-Driven Development is a powerful way to produce well designed code
with fewer defects”

- Martin Fowler
“Fewer defects, less debugging, more confidence, better design, and higher
productivity in my programming practice”

- Kent Beck
Benefits of TDD (1/3)
Benefits on your design & code
• Exposes design flaws & invalid assumptions
• Simpler class hierarchies
• Less code, smaller functions
• Less conditional code
• Faster development time

• Tests are both design & documentation
Benefits of TDD (2/3)
Benefits on your tests & bugs
• Tests cover *everything*
• Bugs found earlier & faster
• Bugs reproduced more easily
• Less (difficult) debugging
Benefits of TDD (3/3)
Cost of change

Test-Driven Development embraces change!
Waterfall
Cons of TDD
•
•
•
•

Needs practice, but you’ll learn to love it!
Needs discipline
Need to know OODP
Scares away managers
Bowling game
First a quick design session…
Bowling game
0 4
4

2 4
10

4 3
17

4 + (2+4)

•
•
•
•

6
30

3 2
35

55

9
65

0 0
65

9 0
74

7 2
83

17 + (6+4+3) 35 + (10+9+1) + 1 + 0)
55 + (9

10 frames, each holds 2 throws
Spare: 10 pins 2nd try, next throw added extra
Strike: 10 pins in 1st try, score next frame added
10th frame spare or strike,
player can make extra balls to complete frame.
Quick design sessions
next frame

Frame

Game
+roll(pins : int)
+score() : int

The score for spare or strike
depends on the frame’s succesor

10

+score() : int

Roll
1..2

-pins : int

1

We clearlyfunction must A game has ten frames. A frame has 1 or 2 roles.
The score need the Game class.
iterate
through all the frames, and
calculate all their scores.
tenth frame

The tenth frame has two or three roles.
It is different from all the other frames.
Bowling game
Finally some code!
Key rules of TDD
A test is no unit test if…
• …it talks to a database
• …it communicates across the network
• …it touches the file system
• …it can’t run at the same time as other tests
• …you have to perform actions to run the tests
(ex. configuration change)
How to isolate your code
How to isolate your code

database

logging
service

remote
server
How to isolate your code
Mocks & Stubs
A mock or stub is a stunt double for…
• …an object outside your unit
• …an external object (database)
• …a complex object(s)
• …a not yet developed object

Mocking & Stubbing are different things!
Isolation framework
[TestMethod]
public void Does_AllowDependencyInjection_When_CreatingInstance()
{
// Arrange
var fake = Isolate.Fake.Instance<ICustomerRepository>();
Customer cust = new Customer();
// Act
BusinessAction ba = new BusinessAction(fake);
ba.PerformSomeSortOfAction(cust);

// Assert
Isolate.Verify.
WasCalledWithExactArguments(() => fake.SaveChanges(cust));
}
Legacy code
What is legacy code?
Wikipedia : Legacy code is source code that relates
to a no-longer supported or manufactured
operating system or other computer system.

Why is legacy code bad?
• The previous developer isn’t there to explain it.
• It takes time to learn the code.
• It’s not easy to change the code.
• You might break some part of the application
you didn’t even touch.
Legacy code
Now imagine...
Without a tests,
• You’re developer on unitproject,
What if you have unit tests? as we speak!
you’re writing legacy code
• You get sick for two weeks,
• Yourhave tests to explain the code
You code needs to be completed,
• Another developer comes in.
You have tests to learn the code
© Michael Feathers – Working Effectively with Legacy Code

You have tests to verify what you did works,
and did not break any other part of the
application.

- The previous developer isn’t there to explain it.
- It takes time to learn the code.
- It’s not easy to change the code.
- You might break some part of the application you didn’t even touch.
Conclusion:

WRITE UNIT TESTS!
and do it the right way using Test-Driven Development.
Thank you for your attention
• Dennis van der Stelt
– Dennis@BloggingAbout.NET
– http://twitter.com/dvdstelt/
– http://bloggingabout.net/blogs/dennis/
Resources to more information can be found here, incl. this slidedeck.
Evaluation form
Vul je evaluatieformulier in en maak kans
op een van de prachtige prijzen!!
Fill out your evaluation form and win one of
the great prizes!!

Session Code: NE.17

Test Driven Development

  • 1.
    Dennis van derStelt Introduction in the TDD Mantra Session Code: NE.17
  • 2.
    Introduction • Class-A – – – – Kennisprovider Microsoft development Training/ Coaching www.class-a.nl • Dennis van der Stelt – Trainer / Coach – Weblog at http://bloggingabout.net/blogs/dennis/
  • 3.
    Agenda • • • • • • • • A quick introductioninto unit testing Test Driven Development mantra Refactoring Benefits of Test Driven Development Demo Key rules of Test Driven Development Mocking / Stubbing Legacy code
  • 4.
    A quick introduction Unittesting 1. Automated testing 2. Facilitates change 3. Simplifies integration 4. Documentation
  • 5.
    unit testing isn’tabout just testing code it‘s about allowing you to determine when behavior changes
  • 6.
    TDD Mantra RED GREEN I’M TEST-DRIVEN • • • • Writethe test Write the code Refactor Repeat REFACTOR
  • 7.
    TDD Mantra Where tobegin? • Work from specification (or notes, or napkin) • Create a list of tests • Pick the simplest one • Make test, make code • Refactor • Find a bug? Create the test that would’ve caught it!
  • 8.
    Test Driven Development ...isnot about testing. • It’s about design • It’s about unambigious requirements • It’s also about simplicity and YAGNI Simplicity is more complicated then you think. But it’s well worth it. Ron Jeffries, Extreme Programming Installed, 2001
  • 9.
    Test Driven Development ...isabout simple design that 1. 2. 3. 4. Runs all tests Reveals all intention Has no duplication Has the fewest number of classes and methods
  • 10.
    Test Driven Development “Theact of writing a unit test is more an act of design then of verification” - Robert C. Martin “Test-driven development seeks specification, not validation, letting you think through your design before you write your functional code” - Scott Ambler “Test-Driven Development is a powerful way to produce well designed code with fewer defects” - Martin Fowler “Fewer defects, less debugging, more confidence, better design, and higher productivity in my programming practice” - Kent Beck
  • 11.
    Benefits of TDD(1/3) Benefits on your design & code • Exposes design flaws & invalid assumptions • Simpler class hierarchies • Less code, smaller functions • Less conditional code • Faster development time • Tests are both design & documentation
  • 12.
    Benefits of TDD(2/3) Benefits on your tests & bugs • Tests cover *everything* • Bugs found earlier & faster • Bugs reproduced more easily • Less (difficult) debugging
  • 13.
    Benefits of TDD(3/3) Cost of change Test-Driven Development embraces change! Waterfall
  • 14.
    Cons of TDD • • • • Needspractice, but you’ll learn to love it! Needs discipline Need to know OODP Scares away managers
  • 15.
    Bowling game First aquick design session…
  • 16.
    Bowling game 0 4 4 24 10 4 3 17 4 + (2+4) • • • • 6 30 3 2 35 55 9 65 0 0 65 9 0 74 7 2 83 17 + (6+4+3) 35 + (10+9+1) + 1 + 0) 55 + (9 10 frames, each holds 2 throws Spare: 10 pins 2nd try, next throw added extra Strike: 10 pins in 1st try, score next frame added 10th frame spare or strike, player can make extra balls to complete frame.
  • 17.
    Quick design sessions nextframe Frame Game +roll(pins : int) +score() : int The score for spare or strike depends on the frame’s succesor 10 +score() : int Roll 1..2 -pins : int 1 We clearlyfunction must A game has ten frames. A frame has 1 or 2 roles. The score need the Game class. iterate through all the frames, and calculate all their scores. tenth frame The tenth frame has two or three roles. It is different from all the other frames.
  • 18.
  • 19.
    Key rules ofTDD A test is no unit test if… • …it talks to a database • …it communicates across the network • …it touches the file system • …it can’t run at the same time as other tests • …you have to perform actions to run the tests (ex. configuration change)
  • 20.
    How to isolateyour code
  • 21.
    How to isolateyour code database logging service remote server
  • 22.
    How to isolateyour code
  • 23.
    Mocks & Stubs Amock or stub is a stunt double for… • …an object outside your unit • …an external object (database) • …a complex object(s) • …a not yet developed object Mocking & Stubbing are different things!
  • 24.
    Isolation framework [TestMethod] public voidDoes_AllowDependencyInjection_When_CreatingInstance() { // Arrange var fake = Isolate.Fake.Instance<ICustomerRepository>(); Customer cust = new Customer(); // Act BusinessAction ba = new BusinessAction(fake); ba.PerformSomeSortOfAction(cust); // Assert Isolate.Verify. WasCalledWithExactArguments(() => fake.SaveChanges(cust)); }
  • 25.
    Legacy code What islegacy code? Wikipedia : Legacy code is source code that relates to a no-longer supported or manufactured operating system or other computer system. Why is legacy code bad? • The previous developer isn’t there to explain it. • It takes time to learn the code. • It’s not easy to change the code. • You might break some part of the application you didn’t even touch.
  • 26.
    Legacy code Now imagine... Withouta tests, • You’re developer on unitproject, What if you have unit tests? as we speak! you’re writing legacy code • You get sick for two weeks, • Yourhave tests to explain the code You code needs to be completed, • Another developer comes in. You have tests to learn the code © Michael Feathers – Working Effectively with Legacy Code You have tests to verify what you did works, and did not break any other part of the application. - The previous developer isn’t there to explain it. - It takes time to learn the code. - It’s not easy to change the code. - You might break some part of the application you didn’t even touch.
  • 27.
    Conclusion: WRITE UNIT TESTS! anddo it the right way using Test-Driven Development.
  • 28.
    Thank you foryour attention • Dennis van der Stelt – Dennis@BloggingAbout.NET – http://twitter.com/dvdstelt/ – http://bloggingabout.net/blogs/dennis/ Resources to more information can be found here, incl. this slidedeck.
  • 29.
    Evaluation form Vul jeevaluatieformulier in en maak kans op een van de prachtige prijzen!! Fill out your evaluation form and win one of the great prizes!! Session Code: NE.17