Driving application development through behavior driven development

Driving application development through behavior driven development

• 2.
  Driving application development through Behavior Driven Development by Einar Ingebrigtsen
• 3.
  Who am I? Consultant DoLittle Studios Silverlight MVP [email protected] twitter.com/einari http://www.ingebrigtsen.info
• 4.
  Who am I? Authorof 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 TypemockIsolator / 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 ofunit 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 “Oneof 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 testsare 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 all9...
• 13.
  Lets talk about behaviors...
• 14.
  Background • Coined byDan North in 2006 article in Better Software magazine • Reaction to TDD • Focus on behaviors of your system
• 15.
  Dialogue • Improves thedialog 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 onbusiness value; hence behavior in the system • Your system doesn’t work with data - but behavior that might result in data
• 17.
  Where does itapply? • 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 readableDSL • 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 behaviorof the unit • Tests interaction between systems • Focus on decoupling
• 22.
  Test Doubles • Provideimplementations 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 cannedanswers • May record information about calls being made to it
• 25.
  Mocks • Objects preprogrammedwith 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 canuse 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-intest 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 morething ..
• 39.
  .. go andcreate software with less bugs.. :)