TDD Painkillers

C# TDD Painkillers
@Ben_Hall
Ben@BenHall.me.uk
Blog.BenHall.me.uk
CodeBetter.com/blogs/BenHall
http://www.flickr.com/photos/pinksherbet/4004791663/

London based ASP.net MVPWeb Developer @ 7digital.com
Open Source Developer
WHO AM I?
Co-Author
Testing ASP.net Web Applications
www.testingaspnet.com

You
Test Design
App Design

http://www.flickr.com/photos/chiotsrun/4115059294/sizes/l/

Test Design
http://www.flickr.com/photos/nyuhuhuu/4442144329/

TDD doesn’t mean NUnit

TDD is about learning

TDD is about validating the unknowns
Proving your own assumptions

Fundamentally the biggest TDD painkiller is not doing TDD

That’s why we have a QA department

Ideally Pairing
Developer writing the testDeveloper writing the implementation

Do enough just to get the test to pass
Write more tests to express more behaviour
Wouldn’t it be cool if...
Loose focus
Takes longer to achieve what you wanted to deliver
Do the simplest thing possible.“First make it work, then make it right”

“TDD like you meant it”

http://www.flickr.com/photos/peasap/1625639532/sizes/l/
Spike

IRB (Ruby)
Want rapid feedback
Allows you to learn quickly

Spikes
http://github.com/BenHall/CastleDynamicProxy101/blob/master/CastleDynamicProxy101/Program.cs
http://github.com/BenHall/memcached101/blob/master/MemcacheDemo/Program.cs

NUnit makes learning repeatable
Helps guide the learning during implementation

Test Naming and structure
Pain killer

Each test should add something to explain the behaviour of the class under test
As you read down then it should continue to add more information in a logical way
Structure

Bad structure
Method1_does_this
Method2_does_this
Method2_does_something_else
Method1_does_not_do_this
EXAMPLE

Bad structure
Method1_does_this
Method1_does_not_do_this
Method2_does_this
Method2_does_something_else
EXAMPLE

Context Spec
Taken from Ruby
Example if the Persistent DLR integration

Naming of test
Implementation
I follow a BDD style which explains the behaviour
If your naming talks about implementation, then your likely to test implementation – this could change!
Like comments, you don’t want the test naming to be out of sync with what the actual test is doing

Actual test implementation
Painkiller

Make sure the important details are easy to identify
Hide the irrevent information to identify which bits are key
Variable names can help with this
varexpiredCreditCardDate = ...
Highlight relevant data

Duplicated Setup in test
Use Setup
Make test helpers which have pre-defined stub configs
EXAMPLE

Tests are documentation

IT DEPENDS

Given, When, Then

Scenario: Payment method has expired
Given user John
And John has expired credit card
When I get the default payment method
Then an invalid credit card will be returned
Cuke4nuke SpecFlow

Design smells indicate it’s not done via TDD

Random, Dates, Machine Settings
DateTime.Now();
new Random().Next();

DateTimefunc
Random func
Use staticFunc<T>

EXTERNAL DEPENDENCIES
http://www.flickr.com/photos/gagilas/2659695352/

Fake the other side

Mock External Dependencies

Anti Corruption
http://www.flickr.com/photos/aresauburnphotos/2678453389/sizes/l/

Mock Usage
Not doing Unit Testing if you don’t use mocks
Over usage
ASP.net MVC is perfect example of having to do this
Stubs return stubs returning stubs
Too many mocks
Mocking things you don’t own
HttpContextBase
IDbConnection

http://ayende.com/Blog/archive/2006/07/02/DoNOTMockSystemData.aspx

Fragile to refactoring
Focusing too much on implementation
Needs to be behaviour driven
Incorrect Responsbilities

Running away from HttpContext

Interfaces establish behaviour boundaries. StubMock at boundaries

Let the tests drive the design
Scares some people. But again, it’s a learning tool so let it educate you!

http://www.flickr.com/photos/yakobusan/2436481628/
Application Design

Dependencies
IoC – Fear
TDD + IoC + Dependencies can lead to a very different application design
Fear is mainly because

Poor man’s IoC

REALLY?!?

Design Smell
Responsibilities of the class being tested
Fixture talks about lots of different concepts
Context Spec makes this a lot easier to identify
Easier to see if structured correctly
Smell - Responsibilities
http://www.flickr.com/photos/ricmcarthur/56268640/

Catalogue Handler
Tests help indicate smells

Catalogue Handler
Tests help indicate smells
Abstract away?
Combined service?

Single responsibility principle
Open/closed principle
Liskov substitution principle
Interface segregation principle
Dependency inversion principle

UI Testing
http://blig.ig.com.br/brokenarrow/files/2009/04/too_many_toolbars.jpg

WPF Apps With The Model-View-ViewModel Design Pattern
MVVM Pattern
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

MVP Pattern

Acceptance Test Driven Development

http://codebetter.com/blogs/benhall/archive/2010/03/16/testing-a-wpf-ui-using-ruby-cucumber-and-wipflash-dll.aspx

Scenario: Saving a product by name only Given the application has started And I enter the name "Product 1" When I save the product Then "Product 1" should be available to purchase

Given /^the application has started$/ do host = ApplicationLauncher.new @app = host.launch Dir.pwd + '/src/ExampleUIs/bin/Debug/ExampleUIs.exe' @main_window = @app.find_window 'petShopWindow' end Given /^I enter the name "([^"]*)"$/ do |product_name| textbox = @main_window.find_TextBox "petNameInput" textbox.text = product_name end When /^I save the product$/ do button = @main_window.find_Button "petSaveButton" button.click sleep(1) end Then /^"([^"]*)" should be available to purchase$/ do |product_name| combo = @main_window.find_ComboBox "basketInput" combo.Items.should include("Pet[#{product_name}]") end After do |scenario| @app.process.kill end

Full stack testing for ATDD?
Waste of time!
Feature coverage
Can be used as part of a test metric

What’s good application design?
When you read the code, it’s what you expect
How quickly you can add tests
How quickly you can implement new functionality
Understandable by the team
How much code churn ework is being performed
How much test coverage

Code Coverage
Waste of time!
Feature coverage
Can be used as part of a test metric

Code and Test Reviews
Better than metrics
What the team thinks is good

7digital XTCR – Cross Team Code Review
At 7digital

It’s all about the mindset

Hardest part == getting started

Second hardest part == keep doing it

Becomes natural

Pair with someone
http://www.flickr.com/photos/jasohill/65804069/sizes/l/

Kata
http://www.flickr.com/photos/53511700@N06/4944542750/sizes/l/

Biggest Painkiller
Lizard Brain
Just do it!
Fear
http://www.flickr.com/photos/bartt/34937855/

End of the line
http://www.flickr.com/photos/leon_homan/2856628778/

Summary
Let the tests drive your design
Listen for smells
Fear – beat the lizard brain
just do it!

@Ben_Hall
Ben@BenHall.me.uk
Blog.BenHall.me.uk
http://www.flickr.com/photos/mike_c/4780493909/

http://blog.benhall.me.uk	1769
http://localhost	84
http://feeds.feedburner.com	39
http://localhost:3004	10
http://mrk-et.herokuapp.com	3
http://static.slidesharecdn.com	3
http://mayday-et.herokuapp.com	3
http://md-et.herokuapp.com	2
http://webcache.googleusercontent.com	1
http://translate.googleusercontent.com	1

TDD Painkillers

by Ben Hall on Oct 09, 2010

Accessibility

Tags

Upload Details

Usage Rights

10 Embeds 1,915

Statistics

TDD Painkillers — Presentation Transcript