{"id":696,"date":"2009-02-23T11:31:51","date_gmt":"2009-02-23T10:31:51","guid":{"rendered":"http:\/\/www.navision-blog.de\/2009\/02\/23\/introducing-naturalspec-a-dsl-for-testing-part-i\/"},"modified":"2009-11-08T11:13:35","modified_gmt":"2009-11-08T10:13:35","slug":"introducing-naturalspec-a-dsl-for-testing-part-i","status":"publish","type":"post","link":"http:\/\/www.navision-blog.de\/blog\/2009\/02\/23\/introducing-naturalspec-a-dsl-for-testing-part-i\/","title":{"rendered":"Introducing NaturalSpec – A Domain-specific language (DSL) for testing – Part I"},"content":{"rendered":"

Test-Driven development (TDD<\/a>) is a well known software development technique and follows the mantra \u201cRed-Green-Refactor<\/a>\u201d. Behavior-Driven Development (BDD<\/a>) is a response to TDD and introduces the idea of using natural language to express the Unit Test scenarios.<\/p>\n

There are a lot of popular testing frameworks around which can be used for BDD including xUnit.net<\/a> ,NUnit<\/a>, StoryQ<\/a>, MSpec<\/a>, NSpec<\/a> and NBehave<\/a>. Most of them can be used with fluent interfaces<\/a> and therefore provides a good readability of the sources. Some of them even provide the possibility to generate a spec in natural language out of passed Unit tests.<\/p>\n

What is a spec?<\/h5>\n
\n

\u201cA specification<\/strong> is an explicit set of requirements to be satisfied by a material, product, or service.\u201d<\/p>\n

American Society for Testing and Materials (ASTM<\/a>) definition<\/p>\n<\/blockquote>\n

A spec is an important document for the communication process \u2013 it enables domain experts to communicate with developers. But how can you verify the compliance with the spec? The answer is: you have to write unit tests. Even with the mentioned frameworks there is a lot of work to do in order to translate a spec scenario into a Unit Test.<\/p>\n

\n

Question 7 in the famous Joel Test<\/a> is \u201cDo you have a spec?\u201d.<\/strong><\/p>\n<\/blockquote>\n

The idea of NaturalSpec<\/a> is to give domain experts the possibility to express their scenarios directly in compilable Unit Test scenarios by using a Domain-specific language<\/a> (DSL) for Unit Tests. NaturalSpec is completely written in F#<\/a> \u2013 but you don\u2019t have to learn F# to use it. You don\u2019t even have to learn programming at all.<\/p>\n

Example 1 \u2013 Specifying a list<\/h5>\n

Let\u2019s consider a small example. If we want to test a new List implementation a spec could look like this:<\/p>\n

[<Scenario>]\nlet <\/span>When_removing_an_3_from_a_small_list_it_should_not_contain_3() =\n  Given [1;2;3;4;5]              \/\/ \u201cArrange<\/strong>\u201d test context\n    <\/span>|> When removing 3           \/\/ \u201cAct<\/strong>\u201d\n    <\/span>|> It shouldn't contain 3    \/\/ \u201cAssert<\/strong>\u201d\n    <\/span>|> It should contain 4       \/\/ another assertion\n<\/span>    |> Verify                    \/\/ Verify scenario<\/span><\/pre>\n
I used BDD style<\/a> here and expressed my scenario in a quite natural language. As the comments are indicating the scenario is following the Arrange Act Assert (\u201cAAA\u201d) pattern.<\/p>\n
With the Keyword \u201cGiven<\/strong>\u201d I can create a test context (the objects I want to test). In this sample I created a list with 5 elements. With the keyword \u201cWhen<\/strong>\u201d I call a function which does something with my test context. In this case I want to remove the value 3. In the Assert section (keywords \u201cIt should<\/strong>\u201d or \u201cIt shouldn\u2019t<\/strong>\u201d) I can give some observations, which should hold for my manipulated test context.<\/p>\n
When I run this scenario via a NUnit runner (i am using TestDriven.Net<\/a>) I get the following output:<\/p>\n
\n
Scenario: When removing an 3 from a small list it should not contain 3<\/p>\n
– Given [1; 2; 3; 4; 5]
\n    – When removing 3
\n    => It should not contain 3
\n    => It should contain 4
\n    ==> OK<\/p>\n<\/blockquote>\n
Example 2 \u2013 Specifying a factorial function<\/h5>\n
If you implement factorial<\/a> function the spec could look like this:<\/p>\n
[<Scenario>]\nlet <\/span>When_calculating_fac_5_it_should_equal_120() =\n  Given 5\n    |> When calculating factorial\n    |> It should equal 120\n    |> Verify    \n\n[<Scenario>]\nlet <\/span>When_calculating_fac_1_it_should_equal_1() =\n  Given 1\n    |> When calculating factorial\n    |> It should equal 1\n    |> Verify          \n\n[<Scenario>]\nlet <\/span>When_calculating_fac_0_it_should_equal_0() =\n  Given 0\n    |> When calculating factorial\n    |> It should equal 1\n    |> Verify<\/pre>\n
And the output of NaturalSpec would look like this:<\/p>\n
\n
Scenario: When calculating fac 0 it should equal 0<\/p>\n
– Given 0
\n    – When calculating factorial
\n    => It should equal 1
\n    ==> OK<\/p>\n
Scenario: When calculating fac 1 it should equal 1<\/p>\n
– Given 1
\n     – When calculating factorial
\n     => It should equal 1
\n     ==> OK<\/p>\n
Scenario: When calculating fac 5 it should equal 120<\/p>\n
– Given 5
\n    – When calculating factorial
\n    => It should equal 120
\n    ==> OK<\/p>\n<\/blockquote>\n
Getting started<\/h5>\n
Of course you can use NaturalSpec to specify C# objects. I see my post "Using NaturalSpec to create a spec for C# projects<\/a>" for a small sample.<\/p>\n
You can download NaturalSpec at GoogleCode<\/a> and follow the \u201cGetting started\u201d tutorial<\/a> in order to write your first automatically testable spec.<\/p>\n
I am very interested in your feedback. Do you like the syntax? What should I change? Do you consider using a spec tool like NaturalSpec?<\/p>\n","protected":false},"excerpt":{"rendered":"
Test-Driven development (TDD) is a well known software development technique and follows the mantra \u201cRed-Green-Refactor\u201d. Behavior-Driven Development (BDD) is a response to TDD and introduces the idea of using natural language to express the Unit Test scenarios. There are a lot of popular testing frameworks around which can be used for BDD including xUnit.net ,NUnit, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[12,448,524,29],"tags":[533,532,528,529,664,527,666,219,526,531,530,525],"_links":{"self":[{"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/posts\/696"}],"collection":[{"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/comments?post=696"}],"version-history":[{"count":21,"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/posts\/696\/revisions"}],"predecessor-version":[{"id":915,"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/posts\/696\/revisions\/915"}],"wp:attachment":[{"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/media?parent=696"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/categories?post=696"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/tags?post=696"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}