This project is read-only.

Parameters with Spaces

Mar 30, 2010 at 2:42 PM

Hi guys

Thanks for a great tool!

I am trying to generate some C# code for my stories using the StoryQ converter. This works fine for most cases including generating my code with string parameters. However, some of my scenarios have arguments that have spaces in - for instance I pass error messages or phrases into methods.

So for the text:

story is User can Login
in order to access my account details
as a registered user
i want to login to the system

with scenario User does not exist
given the user does not have an account
when I use username $fred
and the username $'does not exist'
then the field Username displays the error $'The username or password is incorrect'

I would like to generate the following code:

new Story("User can Login")
    .InOrderTo("access my account details")
    .AsA("registered user")
    .IWant("to login to the system")

            .WithScenario("User does not exist")
                .Given(TheUserHasAnAccount)
                .When(IUseUsername_, "fred")
                    .And(TheUsername_, "'does not exist")
                .Then(TheFieldUsernameDisplaysTheError_, "The username or password is incorrect")
    .Execute();

However, the generator does not recognize spaces or quoted text and the methods/parameters are a little messed up. Is there a way to get this working out of the box?

I have downloaded the source and modified the StoryCodeGenerator to use a slightly different regex in 'StringToMethodCall' - this works for my case, though my fix doesn't allow escaped single quotes.

What do you guys think about all of this, have I missed an easier way to achieve what I need?


Mar 30, 2010 at 2:53 PM

Hi p3365!

You haven't missed anything. Right now, there's no easy way to generate methods with multi-word string parameters.

I can see it being a typical use case, though, so I'll have a think about how to solve this.

You'd want the quotes to be left out of the string in the generated code, wouldn't you? Did you choose ' instead of " for a particular reason?

 

P.S. I don't know if this is really your code or just an example you put together for us, but I've got an off-topic tip. You can give the "TheUsername_" method a boolean parameter instead of a string and then use a BooleanParameterFormatter to format that boolean into "does not exist" or "exists" if you like...

Mar 30, 2010 at 3:04 PM

Wow, thanks for the immediate response!!!

The usage of ' is just an example, its not preferable to " in any way. Yes, I'd like the quotes to be left out of the string - this was my temporary solution to the problem; as the ' was used to delineate the parameterized text with spaces.

Thanks for the boolean parameter tip. This is a stripped down version of a real case; the text "exists", "does not exist" also has related scenarios such as "is locked" "is cancelled" - so rather than a boolean parameter formatter I'd need one that would generate an enumerated value from the text :) See, if you hadn't mentioned it....

Mar 31, 2010 at 1:34 PM

Again, I'm aware that this is a contrived example (and we're definitely looking at adding multiword string parameters), but you might find that it's easier to replace a single, parameterised step method with 6 cases in a switch statement with 6 distinct step methods

Mar 31, 2010 at 8:19 PM
Edited Mar 31, 2010 at 8:21 PM

Yes, I've done this now. Its certainly more explicit with distinct step methods.

I was looking at allowing my analysts to create their own permutations and combinations of scenarios, so they can add more scenarios with little or no intervention of developers. For instance, some of our our web service methods return status codes as enumerated values. If I parameterize these enumerated values then I can write one step which can potentially generate any of these values (there could be 10 or more values). So the step could remove spaces, apply camel casing and then parse and convert to the enum. My mock web service could then return this value to force the behaviour that I want to test.

Thanks for the help.

Mar 31, 2010 at 8:28 PM

Oh, another thing. This is perhaps a little off-topic, but is slightly related.

My analysts have questioned the readability of the stories that have parameterized steps. They don't like the $ character - they think it makes the stories more difficult to read. I hae pointed out that this is only a problem when they write the original story and scenarios, and when they see the output, they don't have this character and they are perfectly readable.

So, they don't currently put these in, so I have to try and decode which bits are parameterised and add the $ myself. Its a PITA!

Thanks again

Apr 1, 2010 at 7:25 AM
p3365 wrote:

Yes, I've done this now. Its certainly more explicit with distinct step methods.

I was looking at allowing my analysts to create their own permutations and combinations of scenarios, so they can add more scenarios with little or no intervention of developers. For instance, some of our our web service methods return status codes as enumerated values. If I parameterize these enumerated values then I can write one step which can potentially generate any of these values (there could be 10 or more values). So the step could remove spaces, apply camel casing and then parse and convert to the enum. My mock web service could then return this value to force the behaviour that I want to test.

Thanks for the help.

That makes sense :)

p3365 wrote:

Oh, another thing. This is perhaps a little off-topic, but is slightly related.

My analysts have questioned the readability of the stories that have parameterized steps. They don't like the $ character - they think it makes the stories more difficult to read. I hae pointed out that this is only a problem when they write the original story and scenarios, and when they see the output, they don't have this character and they are perfectly readable.

So, they don't currently put these in, so I have to try and decode which bits are parameterised and add the $ myself. Its a PITA!

Thanks again

This is interesting. When we started StoryQ, we had already been using Fitnesse on a project to enable our analysts to write acceptance tests. NBehave and Specflow are a couple of .NET BDD frameworks that support true plain-text scenarios.

We found that left to their own devices, analysts test cases got a bit unmaintainable. What we wanted for StoryQ was for developers to work together with analysts to produce stories. This way, the developer can apply refactoring, parameterisation, can ask the analyst whenever a step narrative isn't clear enough, can break down complex scenarios into multiple ones and vice versa. The analysts shouldn't have to decide what parts of a step are parameters - maybe because your ones are actually confused about what constitutes a parameter they are pretending to not like the $ punctuation :).

At the end of the day, the fact that StoryQ stories are checked in to source control with the rest of the codebase means that the developers can really own it. One thing I didn't like about Fitnesse was that it kept it's own revision history, which would often be out of step with your code's changeset numbers...

I know some people see "non-technical people being able to write acceptance tests without ANY help" as a bit of a holy grail (and plaintext BDD frameworks / Fitnesse are much better at this than StoryQ), but we think that collaboration is really important. Play to each other's strengths :)

Apr 1, 2010 at 8:09 AM
Edited Apr 1, 2010 at 8:11 AM

I too used Fitnesse in the past, I didn't ever get analysts to write stories as they found the wiki environment too alien and confusing. I also looked at Cucumber but never succeeded in getting the damn thing to install and work properly with .Net.

I much prefer the StoryQ way of doing things, where the stories are in a sense "handed over" to the developers who are responsible for them from them on. I am hoping to follow a process similar to this:

  1. The analysts in combination with the users/business, create their plain text stories trying to follow the formal syntax (Gherkin?)
  2. The stories are passed over to the development team who review them and adjust them to make them easier to automate
  3. The stories are then reviewed by the analysts/users to ensure they still make sense
  4. The developers implement the stories
  5. The analysts/users view the latest report from the nightly build indicating the real progress of the development team
  6. When a story is done, the developers hand over the story to system test, with a behavioural description
  7. The system testers verify the story, and do all of the stress/boundary/non-functional testing that they are good at.
  8. When the project is done we have a suite of regression tests and documentation of its behaviour (this is the most important bit for me)

I was not really thinking of the analysts running off and doing their stuff completely independantly to the development team - after all, they know nothing of the magical glue we create to make the automation possible. They probably will never understand why we need to make the tweaks to the stories that we do!

 

 

Apr 1, 2010 at 9:19 AM

Cool :) I'm glad you like StoryQ, and I'm glad it suits your workflow.

Just be careful about using terms like "Hand over" and "Passed over" on an agile project. I've found it's really important for the whole team to feel responsible for everything, otherwise when things go bad it's too easy for one team to blame the other: "You re-wrote my spec!", "But you reviewed my changes!". http://www.ayeconference.com/the-blame-game/

 

Apr 1, 2010 at 9:29 AM

Thanks, good point. Unfortunately in our world the analysts usually write the stories and then get moved onto other projects. I guess I documented their usual practice of throwing their requirements "over the fence" and then running off :)

 

Apr 1, 2010 at 9:33 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Apr 1, 2010 at 9:35 AM

Sounds pretty standard :(

Hey i've created an issue for your request, can you please have a think about the different escaping options i've listed there, and weigh in with a comment or two?

 

Apr 6, 2010 at 2:42 PM

I've "fixed" that issue (which means the fix is in source control, as yet unreleased). I decided that you can have a dollar symbol for $singleWordParameters or curly braces for {multi word parameters}.

Support for named parameters and datetime literals is checked in too now.