prdc11-tdd-common-mistakes

(track sponsor)

Amir Barylko

Common TDD

Mistakes &Pitfalls

Amir Barylko - TDD Mistakes & Pitfalls MavenThought Inc.

AMIR BARYLKOCOMMON TDD

MISTAKES & PITFALLSPRAIRIE DEV CON

REGINA 2011


WHO AM I?

• Architect

• Developer

• Mentor

• Great cook

• The one who’s entertaining you for the next hour!


INTROWhy projects fail?

Reality CheckNo more excuses

Why TDD?


WHY PROJECTS FAIL?

•Delivering late or over budget

•Delivering the wrong thing

•Unstable in production

•Costly to maintain


REALITY CHECK

•It is impossible to gather all the requirements at the beginning of a project.

•Whatever requirements you do gather are guaranteed to change.

•There will always be more to do than time and money will allow.


NO MORE EXCUSES

• It works on my computer!

• It was like that when I got here!

• The previous developer didn’t know XXXX!

• We need a satellite connection in order to run it!

• We can’t reproduce the error!

• We can’t test that!


WHY TDD?

•Prove that your code works

•Avoid waste (debugging)

• Increment code quality

•Better design

•Regression tests as byproduct

•Make changes with confidence

•Bring back the joy of coding!


RED GREEN REFACTOR

• Always start with red

• Minimum amount of code to get green

• Refactor if necessary

• Gain confidence

• When in doubt, write a test

Amir Barylko - Common mistakes and pitfalls MavenThought Inc.

THE LIST


TEST IDENTIFICATION

• Unit

• Integration

• Acceptance

• Which one should I use?

• What are the limits?


UNIT

public class When_movie_library_adds_a_movie { public void Should_include_all_the_movies_in_the_contents()}

• One class

• One method

• No dependencies


INTEGRATION

public class When_movie_library_sends_a_tweet{ public void Should_send_a_tweet_with_new_movies()}

• Two or more classes

• Validate interaction between classes

• Still white box testing


ACCEPTANCE

Scenario: Get presenters as JSON

Given I have some speakers at the conference When I get "speakers" as JSON Then I should get a response with all the speakers

• Black box testing

• Manipulate the application

• Populate the database with expected data

• Validate using the application values


ONE SCENARIO PER TEST

• Easy to approach

• Easy to understand

• Easy to maintain


EVERYTHING TOGETHER

[TestFixture]public class MovieLibraryTest{ [Test] public void When_Initialized_Should_Be_Empty()

[Test] public void When_Adding_Should_Appear_In_The_Contents()

[Test] public void When_Adding_Should_Trigger_Event()

[Test] public void When_ListingNV_Should_Ask_Critic()

[Test] public void When_ListingNV_Should_Return_All_NV()

[Test] public void When_ListingNV_Should_Throw_Exception_If_Missing_Critic()}


SCENARIO IDENTIFICATION

1.Initialize1.1.Library should be empty

2.Addingd Movies

2.1.Contents are changes

2.2.Event is triggered

3.Listing NV movies

3.1.Missing Critic

3.2.Listing only NV


ADDING MOVIES

public class When_movie_library_adds_a_movie

{

public void Should_include_the_movie()

public void Should_notify_an_element_was_added()

}


LISTING NV MOVIES

public class When_movie_library_list_nv_with_no_critic

{

public void Should_throw_missing_critic_exception()

}

public class When_movie_library_lists_nv_movies

{

public void Should_return_all_the_nv_movies()

}


WHO’S YOUR DD?

• Quality Driver

• Use the methodology

• Gain confidence

• Don’t show off


THE TEST

public class When_creating_cells{ public void Should_not_be_alive() { var cell = new Cell();

cell.Alive.Should().Be.False(); } }


MAKE IT PASS

• Minimum amount of code

• Don’t think about what’s next

• One bit of code at a time

• Let the technology drive

• Now, make it fail!

public class Cell{ public bool Alive { get { return xxxx? } }}


BEHAVIOUR VERIFICATION

• Test setters and getters

• Verify the dependencies called

• Test private members

• How do I know when’s enough?


TESTING THE CALL

public class When_movie_library_lists_nv_movies { public void Should_return_all_the_nv_movies()

public void Should_call_the_critic_3_times()}


SPECIFY BEHAVIOUR

• Avoid testing implementation

• Setup all the behaviour

• Find the scenario that fails

• Test calls if can’t be verified otherwise


LACK OF AUTOMATION

• Who runs the test?

• Who’s in charge of deployment?

• Who enforces policies on commit?

• Where’s the documentation?

• Do I need the IDE in order to build?


ITERATION 0

• Run all the tests since day one

• Commit should trigger build

• Build should trigger test

• Test may trigger deploy

• Scripts should run locally


LEGACY CODE

• The code is a mess

• Can’t refactor easily

• No documentation

• No testing

• Who dares to make a change?


WHAT TO DO?

• Acceptance tests to document current features

• Migrations to capture current database

• Migrations to capture changes and population

• Unit test works better for new modifications


DEPENDENCIES

• Hardcoded dependencies

• Unit or integration test?

• Isolation


SOMETHING SMELLS

public class MovieLibrary {

private TwitterNotifier _notifier;

public MovieLibrary() {

this._notifier = new TwitterNotifier();

}

}


EXTRACT DEPENDENCIES

public class MovieLibrary {

private INotifier _notifier;

public MovieLibrary(INotifier notifier) {

this._notifier = notifier;

}

}

• Introduces dependency in the constructor / setter

• Easy to test and maintain


RANDOM VALUES

• Are u kidding?

• How do I know are the right values?

• How do I know is not going to fail the next one?


TEST WITH PARAMETERS

• Avoid duplication and repetition

• Generic Parameters

• Parameters Factories

• Random strings

• Random numbers

[Row(1)][Row(2)]void Method(int arg)

[Factory(...)]void Method(string arg)

void Method([Random]...)

void Method([Random]..., [Factory]...)

[Row(typeof(...))]void Method<T>(...)

Amir Barylko - Common mistakes and pitfalls MavenThought Inc.

QUESTIONS?


RESOURCES

• Contact me: [email protected], @abarylko

• Download: http://www.orhtocoders.com/presentations

• Books: The rSpec book, xUnit Patterns.


RESOURCES II

• NUnit: http://www.nunit.org

• Gallio & MbUnit: http://www.gallio.org

• MavenThought Testing: http://maventcommons.codeplex.com

• Rhino Mocks: http://www.ayende.com

• StructureMap: http://structuremap.sourcefore.com

• TeamCity: http://www.jetbrains.com

prdc11-tdd-common-mistakes

Technology

movie public void

nv test public void

movies public void

critic test public void

event test public void

testpublic void

test easy

listing nv moviespublic