PRDC11-tdd-common-mistakes

(track sponsor)

Common
TDD
Mistakes &
Pitfalls
Amir Barylko

AMIR BARYLKO
COMMON TDD
MISTAKES & PITFALLS
PRAIRIE DEV CON
REGINA 2011

Amir Barylko - TDD Mistakes & Pitfalls MavenThought Inc.

WHO AM I?

• Architect

• Developer

• Mentor

• Great cook

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


INTRO
Why projects fail?
Reality Check
No 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! • We need a satellite
connection in order to
• It was like that when I got run it!
here!
• We can’t reproduce the
• The previous developer error!
didn’t know XXXX!
• We can’t test that!


WHY TDD?

• Prove that your code • Regression tests as
works byproduct
• Avoid waste • Makechanges with
(debugging) conﬁdence
• Increment code quality • Bring
back the joy of
coding!
• Better design

RED GREEN REFACTOR

• Always start with red

• Minimum amount of code to get green

• Refactor if necessary

• Gain conﬁdence

• When in doubt, write a test


THE LIST

Amir Barylko - Common mistakes and pitfalls MavenThought Inc.

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.Initialize 3.Listing NV movies
1.1.Library should be empty
3.1.Missing Critic
2.Addingd Movies 3.2.Listing only NV
2.1.Contents are changes

2.2.Event is triggered


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 conﬁdence

• 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 public class Cell
{
• Don’t think about what’s public bool Alive
{
next get { return xxxx? }
}
• One bit of code at a time }

• Let the technology drive

• Now, make it fail!


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 veriﬁed 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 modiﬁcations


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
[Row(1)]
• Avoid duplication and [Row(2)]
repetition void Method(int arg)
[Row(typeof(...))]
• Generic Parameters void Method<T>(...)

• Parameters Factories [Factory(...)]
void Method(string arg)
• Random strings void Method([Random]...)

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


QUESTIONS?

Amir Barylko - Common mistakes and pitfalls MavenThought Inc.

RESOURCES

• Contact me: amir@barylko.com, @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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a PRDC11-tdd-common-mistakes

Similar a PRDC11-tdd-common-mistakes (20)

Más de Amir Barylko

Más de Amir Barylko (20)

Último

Último (20)

PRDC11-tdd-common-mistakes