Our practice is really DDT i.e. Development-Driven Tests, as opposed to TDD (Test-Driven Development).\n\t<\/p>\n
The Missing Ingredient In The Recipe<\/h3>\n
\n\tSo an ingredient is missing: how to get developers to absorb the new functionality in palatable chunks while yet conjuring and capture the interesting scenarios that might influence the structure of the code.\n\t<\/p>\n
Focus on Behavior And Acceptance Is Key<\/h3>\n
\n\tMy outside-work interests in Ruby, Web Frameworks, and Agile approaches recently brought me to dig into the different types of testing frameworks associated with Rails projects such as:\n\t<\/p>\n
- \n
- RSpec<\/a> – the father of Ruby-based BDD frameworks<\/li>\n
- Shoulda<\/a> – alternative to RSpec trying to make the syntax a bit easier to read<\/li>\n
- Cucumber<\/a> – set the tone by focusing the author on the “Given-When-Then”<\/a> structure<\/li>\n<\/ul>\n
\nThere are probably other frameworks but so far I have only looked into these three.
\nThese frameworks aim at raising the level of abstraction above the traditional “x-unit”-style unit tests which are typically focused on defining test methods containing specific code-level assertions such as:\n\t<\/p>\n- \n
- TestUnit Example:<\/li>\n
\r\nclass MyTest < Test::Unit::TestCase\r\n def do_some_work\r\n # ...\r\n assert_equal(\"OK\", result)\r\n end\r\nend\r\n<\/pre>\n
- Rspec Example:<\/li>\n
\r\nrequire 'rubygems'\r\nrequire 'spec'\r\n\r\ndescribe \"Skills Tracking\" do\r\n\tit \"should track skills for a given user\" do\r\n\tend\r\nend\r\n<\/pre>\n
Running the spec produces:
\n![](\".\/wp-content\/uploads\/2009\/07\/RSpec-Demo.png\"\/)
<\/p>\n<\/ol>\nThese frameworks are very convenient to build acceptance either ahead or during development but they still set the expectation that you are writing at least some minimal code. You will also notice that even though help create what is called \"syntactic sugar\" to help with readability, authoring a spec requires that you at least know quite a bit the syntax. What if the abstraction level could be raised one more level and guide you through the BDD process?<\/p>\n
Adding Cucumber To The Recipe<\/h3>\n
\n\tWell, search no more! Cucumber help focus the author on the key tenet of BDD:\n\t<\/p>\n
- \n
- Define each business Feature<\/a> - using the syntax:<\/li>\n
- \n
- In order<\/a> to...<\/li>\n
- As a<\/a>...<\/li>\n
- I want<\/a>...<\/li>\n<\/ul>\n
\r\nFeature: Skills Tracking\r\n In order to manage my skills\r\n As a person continuously developing skills \r\n I want to be track my skills\r\n<\/pre>\n
- Define multiple Scenario<\/a>s where a feature<\/a> can be exercised - using the syntax:<\/li>\n
- \n
- Given<\/a><\/li>\n
- When<\/a><\/li>\n
- Then<\/a><\/li>\n<\/ul>\n
\r\nScenario: Track New Skill\r\n Given a new skill \r\n When I define a new skill\r\n Then the new skill will be tracked\r\n \r\nScenario: Update Skill Proficiency\r\n Given an existing skill \r\n When I have increased my proficiency level with that skill\r\n Then the skill proficiency level will be updated\r\n<\/pre>\n<\/ol>\n
\nNotice that I have not used any code and very minimal syntax. The approach also leads you to define scenarios as you specify your feature. I don't need to think about code quite yet.\n<\/p>\n
Tasting The Cucumber<\/h3>\n
\nSo let's see what minimal infrastructure is needed. I am assuming you have Ruby. If not, check my post titled Getting Started With Ruby And Rails<\/a>.\tTo keep things to a minimum, I am going to show you how to create your features with only Ruby (as opposed to depending on the whole Rails stack).\n\t<\/p>\n
- \n
- Install the cucumber gem<\/li>\n
\r\ngem install cucumber\r\n<\/pre>\n
- Create a project folder (e.g. \"Cuke<\/b>\")<\/li>\n
- Create a file in Cuke<\/b>, name it rakefile<\/b> and edit it to enter the following content:<\/li>\n
\r\nrequire 'rake'\r\nrequire 'rake\/testtask'\r\nrequire 'rake\/rdoctask'\r\n\r\nrequire 'cucumber\/rake\/task'\r\n \r\nCucumber::Rake::Task.new do |t|\r\n t.cucumber_opts = \"--format pretty\"\r\nend\r\n<\/pre>\n
- Create a file in Cuke<\/b>, name it cucumber.yml<\/b> and edit it to enter the following content:<\/li>\n
\r\nautotest: -r features --format pretty --color\r\n<\/pre>\n
- Create a lib<\/b> folder below Cuke<\/b><\/li>\n
- Create a tasks<\/b> folder below Cukelib<\/b><\/li>\n
- Create a file in Cukelibtasks, name it cucumber.rake<\/b> and edit it to enter the following content:<\/li>\n
\r\nbegin\r\n require 'cucumber\/rake\/task'\r\n\r\n Cucumber::Rake::Task.new(:features) do |t|\r\n t.fork = true\r\n t.cucumber_opts = ['--format', (ENV['CUCUMBER_FORMAT'] || 'pretty')]\r\n end\r\n task :features => 'db:test:prepare'\r\nrescue LoadError\r\n desc 'Cucumber rake task not available'\r\n task :features do\r\n abort 'Cucumber rake task is not available. Be sure to install cucumber as a gem or plugin'\r\n end\r\nend\r\n<\/pre>\n
- Create a features<\/b> folder below Cuke<\/b><\/li>\n
- Create a file in Cuke, name it testcuke.feature<\/b> and edit it to enter the following content:<\/li>\n
\r\nFeature: Skills Tracking\r\n In order to manage my skills\r\n As a person continuously developing skills \r\n I want to be track my skills\r\n<\/pre>\n
- Open a command window on our Cuke<\/b> folder and let's run Cucumber<\/li>\n
\r\ncucumber features\/testcuke.feature\r\n<\/pre>\n
The result is:
\n![](\".\/wp-content\/uploads\/2009\/07\/Cukember-Feature-Test.Png\"\/)
- Let's add a scenario to the feature:<\/li>\n
\r\nScenario: Track New Skill\r\n Given a new skill \r\n When I define a new skill\r\n Then the new skill will be tracked\r\n<\/pre>\n
- Let' re-run Cucumber<\/li>\n
\r\ncucumber features\/testcuke.feature\r\n<\/pre>\n
The result is:
\n![](\".\/wp-content\/uploads\/2009\/07\/Cukember-Scenario-Test.Png\"\/)
\nCucumber identified the steps of the scenario and colored them amber to indicate that they are not implemented yet. So let's tackle one step.<\/p>\n- Create a step_definitions<\/b> folder below Cuke<\/b><\/li>\n
- Create a file in Cukestep_definitions<\/b>, name it skill_step.rb<\/b> and edit it to enter the following content based on the template suggested by Cucumber:<\/li>\n
\r\nGiven \/^a new skill$\/ do\r\n pending\r\nend<\/pre>\n
- Let' re-run Cucumber<\/li>\n
\r\ncucumber features\/testcuke.feature\r\n<\/pre>\n
The result is:
\n![](\".\/wp-content\/uploads\/2009\/07\/Cucumber-Step-Test-1.png\"\/)
\nTo make the test pass we would need to fully implement the step.<\/p>\n<\/ol>\nIncremental BDD<\/h3>\n
\nSo far, everytime we have refined the feature, its scenarios and steps, we have re-run cucumber. What if Cucumber could run as soon as a change has been made (i.e. a file has been updated).
\nEnter autotest<\/a>, a \"file-watcher\"<\/b> which will trigger a new run of Cucumber.\n\t<\/p>\n- \n
- Install the ZenTest gem<\/li>\n
\r\ngem install cucumber\r\n<\/pre>\n
- Set the following environment variables in your command line session<\/li>\n
\r\nSET AUTOFEATURE=true\r\nSET HOME=.\r\n<\/pre>\n
- Run autotest<\/li>\n
\r\nautotest\r\n<\/pre>\n<\/ol>\n
\nNow when you make a change to any file, you will see autotest run Cucumber.\n<\/p>\n
So What?<\/h3>\n
\nLooking back at TDD (or DDT!) practices, it is clear that the focus of testing is more on code artifacts than on functional features<\/b>.
\nBehavior-Driven Development\tcan help a development team absorb and distill business requirement<\/b> into acceptance test scenarios from which automated tests can be derived.
\nEven if you are not using Ruby or Rails as your development platform, Cucumber and Ruby can still play a role during the design phase<\/b>. And you can, over time, introduce the use of Ruby to create integration test<\/b> with non-Ruby components either through web services, databases or web clients.
\nIf your core platform is .NET and you are considering building rich clients with Silverlight, you should also consider IronRuby<\/a>. In that scenario, Cucumber can directly be leveraged with IronRuby.
\nOver time, I am envisioning the following for my team:\n\t<\/p>\n- \n
- We start leveraging Cucumber to map some of the key functional requirements into features (but from a developer's standpoint)<\/li>\n
- When ready we derive high-level integration tests using IronRuby<\/li>\n
- We create C#-based unit tests<\/li>\n
- We then combine IronRuby integration tests with lower-level unit test-level harnesses<\/li>\n<\/ul>\n
\nI am clearly planning to further develop my knowledge and experience with BDD through Cucumber.\n<\/p>\n
<\/p>\n
References and Resources<\/h3>\n
Sites:<\/h5>\n
- \n
- BDD<\/a> - Behavior-Driven Development<\/li>\n
- Dan North<\/a> first article on BDD<\/li>\n
- RSpec<\/a> - the father of Ruby-based BDD frameworks<\/li>\n
- Shoulda<\/a> - alternative to RSpec trying to make the syntax a bit easier to read<\/li>\n
- Cucumber<\/a> - set the tone by focusing the author on the \"Given-When-Then\"<\/a> structure<\/li>\n
- Outside-In Development with Cucumber<\/a>: Ben Mabey<\/li>\n<\/ol>\n
Books:<\/h5>\n
- \n
- The RSpec Book<\/a>: Behaviour Driven Development with RSpec, Cucumber, and Friends<\/li>\n<\/ol>\n
Videos:<\/h5>\n
- \n
- Outside-In Development with Cucumber<\/a>: Video of Ben Mabey's presentation<\/li>\n
- Beyond Test Driven Development: Behaviour Driven Development<\/a> - Dave Astels<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
DDT \/ Development-Driven Tests For the last several years I have been generalizing the use of automated unit tests on my team (at work) as part of the development process for our C#-based enterprise services and business applications. Circa 2005, I was using NUnit and NAnt and Cruise Control to implement continuous integrations builds. Then […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21,3],"tags":[55,56],"class_list":["post-158","post","type-post","status-publish","format-standard","hentry","category-bdd","category-ruby","tag-bdd","tag-ruby"],"_links":{"self":[{"href":"https:\/\/blog.monnet-usa.com\/index.php?rest_route=\/wp\/v2\/posts\/158","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.monnet-usa.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.monnet-usa.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.monnet-usa.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.monnet-usa.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=158"}],"version-history":[{"count":7,"href":"https:\/\/blog.monnet-usa.com\/index.php?rest_route=\/wp\/v2\/posts\/158\/revisions"}],"predecessor-version":[{"id":165,"href":"https:\/\/blog.monnet-usa.com\/index.php?rest_route=\/wp\/v2\/posts\/158\/revisions\/165"}],"wp:attachment":[{"href":"https:\/\/blog.monnet-usa.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=158"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.monnet-usa.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=158"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.monnet-usa.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=158"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Beyond Test Driven Development: Behaviour Driven Development<\/a> - Dave Astels<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
- Outside-In Development with Cucumber<\/a>: Video of Ben Mabey's presentation<\/li>\n
- Dan North<\/a> first article on BDD<\/li>\n
- BDD<\/a> - Behavior-Driven Development<\/li>\n
- Create a file in Cuke<\/b>, name it rakefile<\/b> and edit it to enter the following content:<\/li>\n
- When<\/a><\/li>\n
- As a<\/a>...<\/li>\n
- In order<\/a> to...<\/li>\n
- Define each business Feature<\/a> - using the syntax:<\/li>\n
- Shoulda<\/a> – alternative to RSpec trying to make the syntax a bit easier to read<\/li>\n