2. Driving application
development through
Behavior Driven Development
by
Einar Ingebrigtsen

3. Who am I?
Consultant
DoLittle Studios
Silverlight MVP
einar@dolittle.com
twitter.com/einari
http://www.ingebrigtsen.info

4. Who am I?
Author of Balder - 3D engine for Silverlight
http://balder.codeplex.com
Co-author of Bifrost - enterprise app framework
http://bifrost.dolittle.com
Co-author of Forseti - headless JS test runner
http://github.com/dolittlestudios/forseti

5. Win a Typemock Isolator /
Isolator++ License
During the webinar, tweet one cool
takeaway or one tip that you learn with
the hashtag #unittesting and @typemock.
Typemock will then choose a winner and
announce them next week.

6. Retro-style
testing, 1996

7. 9 phases of unit testing
• What is unit testing?
• Refuse to unit test because “you don’t have enough time”.
• Fight it because it means writing more code
• Start unit testing and start blogging / talking about unit testing and TDD and
how great it is
• Unit test everything - make private methods internal and abuse things like
InternalVisibleTo attribute. 100% codecoverage is the only way to fly
• Discover mocking and abuse it
• Mock everything that is possible to be mocked
(like the entire .net framework)
• Start writing effective tests
• Enjoy others trying to figure out why you hardly have any bugs at all

8. Why
• Improve quality
• Add predictability
• Add changeability
• Safety net

9. Test first
“One of the most useful times to write tests is before
you start programming. When you need to add a feature,
begin by writing the test.
By writing the test you are asking yourself
what needs to be done.”
Martin Fowler

10. Continuous
• Your tests are worthless without them being
executed at a certain frequency
• Integrate your tests and production code often
and have your tests along with others run
frequently

11. The 10th phase

12. ... or
skip all 9...

13. Lets talk about
behaviors...

14. Background
• Coined by Dan North in 2006
article in Better Software magazine
• Reaction to TDD
• Focus on behaviors of your system

15. Dialogue
• Improves the dialog with non-developers
• Mindset puts the developer closer to
business value
• Easier for other developers to read
• Easier to get started with testing

16. Mindset
• Focus on business value; hence behavior
in the system
• Your system doesn’t work with data - but
behavior that might result in data

17. Where does it apply?
• In short; everywhere
• It fits perfectly for anything ranging from
acceptance to unit level
• In fact; you might want to stribe towards
using BDD consistently

18. Gherkin
• Business readable DSL
• Introduced by Aslak Hellesøy for
Cucumber in 2008

19. Gherkin
Feature: Addition
In order to avoid silly mistakes
As a math idiot
I want to be told the sum of two numbers
Scenario: Add two numbers
Given I have entered 50 into the calculator
And I have entered 70 into the calculator
When I press add
Then the result should be 120 on the screen

20. Gherkin
Feature: Addition
In order to avoid silly mistakes
As a math idiot
I want to be told the sum of two numbers
Scenario: Add two numbers
Given I have entered 50 into the calculator
And I have entered 70 into the calculator
When I press add
Then the result should be 120 on the screen

21. Units
• Test behavior of the unit
• Tests interaction between systems
• Focus on decoupling

22. Test Doubles
• Provide implementations of dependent
systems that are not real systems
• Good for decoupling

23. Fakes
• Working implementations
• Usually takes shortcuts unsuitable for
production
• In-memory database representations

24. Stubs
• Provide canned answers
• May record information about calls being
made to it

25. Mocks
• Objects preprogrammed with expectations
• Often created adhoc by utilizing
frameworks :
• TypeMock
• RhinoMocks
• Moq
• ... and more ...

26. Writing testable code
• Apply practices such as dependency
inversion principle
• Makes your code decoupled from real
implementations
• In short - S.O.L.I.D. prinicples will get you
there...

27. This changes everything

28. do e
sn’t
This changes everything

29. Writing testable code
• Your code will change - but its a good
thing, its not only for your tests!
• The principles that can be applied are
good software development principles,
regardless of testing or not

30. Frameworks?
• You can use your existing - remember; its
a mindset, not a framework!
• NBehave
• MSpec

31. Structure
(project to specify).Specs
(namespace)
for_(unit to specify)
given
a_(context).cs
when_(behavior to specify).cs

32. Structure
sample
Bifrost.Specs
Commands
for_CommandContext
given
a_command_context_for_a_simple_command_with_one_tracked_object.cs
when_committing.cs

33. Frameworks
• SpecFlow
• StoryQ
• Cuke4Nuke

35. Feedback Loop
• Built-in test runner in Visual Studio is
slow
• TestDriven.net - great alternative
• Auto-test running
• Mighty Mooze - Continuous Test
http://continuoustests.com/
• NCrunch
http://www.ncrunch.net/

36. Recommended
reading
• Dan Norths blog
http://dannorth.net/introducing-bdd/
• http://pragprog.com/book/hwcuc/the-cucumber-book
The Cucumber book
• The RSpec book
http://pragprog.com/book/achbd/the-rspec-book

38. .. one more thing ..

39. .. go and create software
with less bugs.. :)