Presentation about TDD for SDN

1. Dennis van der Stelt
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 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

4. A quick introduction
Unit testing
1. Automated testing
2. Facilitates change
3. Simplifies integration
4. Documentation

5. unit testing isn’t about just testing code
it‘s about allowing you to
determine when behavior changes

6. TDD Mantra
RED
GREEN
I’M TEST-DRIVEN
•
•
•
•
Write the test
Write the code
Refactor
Repeat
REFACTOR

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

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

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

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

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
•
•
•
•
Needs practice, but you’ll learn to love it!
Needs discipline
Need to know OODP
Scares away managers

15. Bowling game
First a quick design session…

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

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

18. Bowling game
Finally some code!

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

20. How to isolate your code

21. How to isolate your code
database
logging
service
remote
server

22. How to isolate your code

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

24. 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));
}

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

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

27. Conclusion:
WRITE UNIT TESTS!
and do it the right way using Test-Driven Development.

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

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