+ All Categories
Transcript
Page 1: Test Driven Development

Session Code: NE.17

Introduction in the TDD Mantra

Dennis van der Stelt

Page 2: Test Driven Development

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/

Page 3: Test Driven Development

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

Page 4: Test Driven Development

A quick introduction

Unit testing

1. Automated testing

2. Facilitates change

3. Simplifies integration

4. Documentation

Page 5: Test Driven Development

unit testing isn’t about just testing code

it‘s about allowing you to

determine when behavior changes

Page 6: Test Driven Development

TDD Mantra

• Write the test• Write the code• Refactor• Repeat

REDRED GREENGREEN REFACTORREFACTOR

I’M TEST-DRIVENI’M TEST-DRIVEN

Page 7: Test Driven Development

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’vecaught it!

Page 8: Test Driven Development

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

Page 9: Test Driven Development

Test Driven Development

...is about simple design that

1. Runs all tests

2. Reveals all intention

3. Has no duplication

4. Has the fewest number of classes and methods

Page 10: Test Driven Development

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

Page 11: Test Driven Development

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

Page 12: Test Driven Development

Benefits of TDD (2/3)

Benefits on your tests & bugs• Tests cover *everything*• Bugs found earlier & faster• Bugs reproduced more easily• Less (difficult) debugging

Page 13: Test Driven Development

Benefits of TDD (3/3)

Cost of change

WaterfallTest-Driven Development embraces change!

Page 14: Test Driven Development

Cons of TDD

• Needs practice, but you’ll learn to love it!• Needs discipline• Need to know OODP• Scares away managers

Page 15: Test Driven Development

Bowling gameFirst a quick design session…

Page 16: Test Driven Development

Bowling game

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

404

4210

3417

630

2335 55

965

0065

0974

2783

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

Page 17: Test Driven Development

Quick design sessions

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

Game Frame

We clearly need the Game class.

A game has ten frames.

-pins : int

Roll

A frame has 1 or 2 roles.

tenth frame

The tenth frame has two or three roles.

It is different from all the other frames.

+score() : int

Frame

The score function must iteratethrough all the frames, andcalculate all their scores.

next frame

The score for spare or strikedepends on the frame’s

succesor

10 1..2

1

Page 18: Test Driven Development

Bowling gameFinally some code!

Page 19: Test Driven Development

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)

Page 20: Test Driven Development

How to isolate your code

Unit testProduction

code

Logging code

Data access code

Web service code

Page 21: Test Driven Development

How to isolate your code

Unit testProduction

code

Logging code

Data access code

Web service code

!! !database logging

serviceremoteserver

Page 22: Test Driven Development

How to isolate your code

Unit testProduction

code

Logging code

Data access code

Web service code

FakeData

access

FakeLogging

FakeWeb

service

Page 23: Test Driven Development

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!

Page 24: Test Driven Development

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

Page 25: Test Driven Development

Legacy code

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.

Wikipedia : Legacy code is source code that relates to a no-longer supported or manufactured operating system or other computer system.

What is legacy code?

Page 26: Test Driven Development

Legacy codeNow imagine...

• You’re developer on a project,• You get sick for two weeks,• Your code needs to be completed,• Another developer comes in.

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

What if you have unit tests?

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

Without unit tests,you’re writing legacy code as we speak!

© Michael Feathers – Working Effectively with Legacy Code

Page 27: Test Driven Development

WRITE UNIT TESTS!Conclusion:

and do it the right way using Test-Driven Development.

Page 28: Test Driven Development

Thank you for your attention

• Dennis van der Stelt– [email protected]– http://twitter.com/dvdstelt/– http://bloggingabout.net/blogs/dennis/

Resources to more information can be found here, incl. this slidedeck.

Page 29: Test Driven Development

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


Top Related