Spec Salad Update

I uploaded a new version of spec salad to the Nuget library today. Primarily this is a compatibility update with the new version of SpecFlow v1.7, and a couple of bug fix’s that I have noticed when using the framework.

There is now syntax for calling a task from a role within the “Given” section of a scenario definition

Given the role attempts to task
Given the role attempts to task: single parameter or name “value pairs”
Given the role attempts to task, single parameter or name “value pairs”
Given the role was able to task
Given the role was able to task: single parameter or name “value pairs”
Given the role was able to task, single parameter or name “value pairs”
Given the role were able to task
Given the role were able to task: single parameter or name “value pairs”
Given the role were able to task, single parameter or name “value pairs”
Given the role did task
Given the role did task: single parameter or name “value pairs”
Given the role did task, single parameter or name “value pairs”

Improved error handling, I discovered that is a role was called that was not previously defined a key not found error was raised, this has been changed so that a SpecSalad exception is now raised with a message stating that the role has not been defined within the scenario.

Because of the update to Specflow 1.7, upgrading from previous versions of SpecSalad you will have to regenerate the code behind file for all the fixture files, as per the upgrade instructions  for Specflow.

I hope people are finding the framework useful, feed back is very welcome, the source is available on git hub here.

Advertisements

About Duncan Butler

Trying to be a very agile software developer, working in C# with Specflow, Nunit and Machine Specifications, and in the evening having fun with Ruby and Rails
This entry was posted in Programming and tagged , . Bookmark the permalink.

6 Responses to Spec Salad Update

  1. George says:

    Hi Duncan,
    I recently discovered the advancements in BDD then SpecFlow and now SpecSalad. Recently I’ve been embracing TDD but found it necessary to drift into BDD, not realizing how late I am even to that game 🙂

    Anyways, you work seems interesting. However, your presentation seems very dependent on people having familiarity with SpecFlow. Consequenty, the ease of entry to your tool is lost in that I now have to go and figure out SpecFlow just to use your tool. In particular, your SpecSalad 1 & 2 examples don’t even show where to store the SpecSalad source your demonstrated.

    Your beautiful house does not have a gate, path, and front door.

    • Welcome to the game, you have a very good point, one which I will have to address, thanks, hopefully I can write a first look series that can address these issues, thanks again for the insight..

  2. Mike Hanson says:

    I know it has been a while since this posting, but I have to disagree with George. To understand the problem that SpecSalad solves you need to undstand SpecFlow and probably have experienced the pain associated with Step Definitions files in SpecFlow. Even if you follow some of the recommendations for organising Step Definitions you will still get to the point where finding existing code is a problem and as has happened on two large projects I have worked on with SpecFlow you end up with duplicate or ambiguous steps.

    Having experienced that pain I am very grateful that Duncan has take the time to create this framework, in a very short space of time it making my life easier and cleaning up our AT code immeasurably.

    I do have one minor gripe, in porting the code I would have preferred you adopted a .NET coding convention and changed some of the names. IMHO underscores make code look ugly and methods like Perform_Task are not really the .NET convention, thankfully code completion makes them less tedious to use than they were in my C++ and Java days but they still look ugly.

    • Thanks for the comment, the naming is a personal thing, something I do within test code (never in production) with an aim of making the code easier to read. Maybe I need to provide an alternative syntax, without the underscores?

      • Mike Hanson says:

        I wouldn’t go as far as complicating things with different syntax, I can live with it as it is. I thought the underscores were a legacy from the ported code.

        I often see underscores in the names of test methods and wince, I personally find it less readable than using PascalCasing, but also I always use ReSharper or CodeRush and as a contractor often am subject to the scrutiny of StyleCop and all of these complain about underscores in names. These Rules can be disabled of course but I agree with them so choose not to and have to live with the occasional nagging. 🙂

  3. I agree with Mike regarding the importance of a new SpecSalad user already being familiar (painfully familiar) with SpecFlow itself.

    I disagree with Mike when it comes to underscores! 🙂 I, too, use underscores quite a bit in my test projects. Because I often have Pascal-cased names within my test names, it’s confusing to lose track of where the original spaces were in the English phrase I’m capturing in my test member names.

    Given a type with the property IsActive, the test method “ReflectionFindsPropertyIsActive” has a very different semantic meaning from a test method named “Reflection_finds_property_IsActive”.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s