Skip "In Order To" & "With Scenario"

Jul 8, 2010 at 6:55 AM

Hello,

I would like to write every test in the StoryQ way, but often especcially for smaller tasks, the need to write a complete and full story creates noise and is cumbersome.

Let's take the following story:

Story is read app settings
  In Order To
  As a Developer
I want to read a app settings file
  With Scenario 
   Given the appSettingsFileReader
   When the appSettingsFileReader.Read is excecuted
   Then the result for $_appSettingsResult.AdminUserName should be $admin_username
    And the result for $_appSettingsResult.AdminPassword should be $admin_password

I really believe the story would be better withoud "In Order To" and "With scenario".

Story is read app settings
 As a Developer
 I want to read a app settings file
Given the appSettingsFileReader
 When the appSettingsFileReader.Read is excecuted
 Then the result for $_appSettingsResult.AdminUserName should be $admin_username
 And the result for $_appSettingsResult.AdminPassword should be $admin_password

What do you think?

Coordinator
Jul 8, 2010 at 9:26 AM
Are you going to be putting "Developer" for all of these "as a" steps?
Jul 8, 2010 at 9:40 AM

Probably yes. But other Roles could be possible, for example: Tester, ContinousIntegrationServer,...

I have Role file which looks currently like that:

	public class Roles
{
public const string Customer = "Customer";
public const string Admin = "Admin";
public const string InstallationOwner = "Owner";
public const string Developer = "Developer";
}
The Story looks like that: 
	new Story("read app settings")			 
.InOrderTo("")  
.AsA(Roles.Developer)  
.IWant("to read a app settings file")
....
Jul 8, 2010 at 9:55 AM

Hello again Robert, hope yous don't mind me posting... For me I'm not 100% convinced with the test here. Reading an app settings file is too technical for a scenario and the testing for that should be done at the unit test level. Reading the app settings file is smaller part of a larger feature. I need to get an example....


Say the feature is to produce a sales report, the steps to do this include reading an app setting file, formatting the data to html, and saving to file.

The story is to produce a sales report. There is no technical information as to how the developer will do that.

	new Story("sales reporting")			 
.InOrderTo("predict future sales")  
.AsA(Roles.Manager)  
.IWant("to produce a sales report"

and so on....it's more business level, a requirement... using the above requirement you can then test the lower level reading the app settings file using unit tests. Now your role can still be developers (as in your developing a software development tool) but again the story is about high level features that, at that level, don't include the technical details of how the feature will be implemented.


Coordinator
Jul 8, 2010 at 10:04 AM
I agree with you, Derek. What I was going to suggest to Robert M was that we (StoryQ) could make the whole Story section optional, and simply letting you start a test with "WithScenario", such as 'WithScenario("reading an app settings file")'. But then I put my BDD, "software that matters" hat. "ContinousIntegrationServer" triggered my memory. I remember Liz Keogh discussing this very subject. If you can't provide justification for this technical feature, then why are you even building it? In Robert's case, I think the story is justifiable. It should be 'InOrderTo("deploy our application into different environments")'. Reading app settings files is one scenario within this story (so again, I'd use 'WithScenario("reading an app settings file")'), and another could be connecting to various servers.
Jul 8, 2010 at 10:54 AM

Hi Rob, pleased to meet you.   I came to reply to my 'Or / And' post but Roberts started a good topic here.

For me the 'InOrderTo' really needs to stay;  "If you can't provide justification for this feature, then why are you even building it?"  yeah that's it exactly Rob.

Actually i was going to suggest changing the order to "AsA->IWant->InOrderTo"  but your putting the benefit first with that ordering!

Roberts story does become more justifyable with an InOrderTo there. There is still technical information, which might be no problem if the user is a developer, but I'm taking the stand point from the User Stories book that says keep technical details away from stories. Should 'reading an app settings file' be 'reading configuration from file' or is that to general, to pedantic. Not sure just thinking out loud.

Yeah Robert the scenario...

  With Scenario 
   Given the appSettingsFileReader
   When the appSettingsFileReader.Read is excecuted
   Then the result for $_appSettingsResult.AdminUserName should be $admin_username
    And the result for $_appSettingsResult.AdminPassword should be $admin_password

It's too technical for me, it's steeped in Readers and method names. It's this as a unit test....

      var appSettingsResult = appSettingsFileReader.Read();
      Assert.Equal("sa", appSettingsResult.AdminUserName);
      Assert.Equal("******", appSettingsResult.AdminPassword);

But treating it as a scenario with StoryQ your splitting that up into 4 methods....Given, When and two Thens.

Any I hope this is helpful feedback...

Jul 9, 2010 at 6:29 PM

I made myself familiar with Liz Keogh's ideas and her Feature-Injection Story-Template. It is compelling :-) I really like that StoryQ enforces it to their users. From my point of view every kind of code should create a business value and should be assignable to an "in order to". Personally i want to replace the classic TDD style (which I tried to follow the last 5 years or so) completely with the StoryQ way BDD Style.

I believe, that I will have a multiple, sometimes a lot, of stories for per business goal. So I started to make them strong typed :-)

	new Story("read a app config ")
.InOrderTo(BusinessGoals.Simplified_administration_of_installations)  
.AsA(Roles.Developer)  

Currently I am really happy with this way to develop. Lets see what experience brings on the table. (According the Liz Koegh the role developer is not appropriate. Probably I will change this and instead start to tag these kind of stories as "technical").

Coordinator
Jul 13, 2010 at 1:54 AM

@robert M - just a comment that I think StoryQ is only part of the testing approach. In C# web apps, I couldn't get by without classical TDD for unit tests - it seems there are parts of the code that I write that are not needing to be that business or analyst facing. StoryQ is a higher level of abstraction and I would have thought that at times using it for classical TDD situations would be quite an overhead. I might in those situations even start using MSpec. For example, yesterday I paired with someone who was doing some Regex on a valid membership number. The business rule was "three letters and then four numbers". I would write a StoryQ test (user story) around the use of a membership number and I would write simple unit tests around the cases of the membership number (eg length, order, caps, encoding). It's just a preference  because I think that is pragmatic, tends to avoid unnecessary repetition and is maintainable by a range of devs over time.

That's just my take on it though.

todd

Jul 13, 2010 at 10:00 AM

Currently I stopped writing classic unit-tests and I am quite happy. I took the membership number example and tried to convert it to the story style.

new Story("Valid membership number")
.InOrderTo(BusinessGoals.Membership.Number_should_be_easy_to_read)
.And(BusinessGoals.Membership.Number_should_not_be_to_guess)
.AsA(Roles.KeyAccountant_Joe_D)
.IWant(The.FollowingBehaviour)
.WithScenario("invalid number"
.Given(TheMemberShipNumberIs"243-4556")
.When(TheMemberShipNumberIsParsed)
.Then(TheNumberShouldBeMembershipNumber.IsInvalid)
.And(TheUserMessageShouldBe"Some great usr msg")

.WithScenario("valid number")
.Given(TheMemberShipNumberIs"243-455")
.When(TheMemberShipNumberIsParsed)
.Then(TheNumberShouldBeMembershipNumber.IsValid)
.And(TheUserMessageShouldBeString.Empty)

.ExecuteWithReport(MethodBase.GetCurrentMethod());

My experience of the last days is, that there is no need for additional unit-tests.

The Business-Goals and Roles are strong typed. That enables reuse and makes it much easier to write new stories.

What do you think?

Coordinator
Jul 13, 2010 at 10:39 AM
@Robert M - I think it's hard to get a very high level of unit test coverage with your approach... Which is probably a good thing! It depends on your situation. If you are finding bugs in production then it's probably worth going heavier on the specification. If not, then you are probably coming up with good (exemplary) examples in your BDD-level tests.
Jul 13, 2010 at 11:25 AM
Edited Jul 13, 2010 at 11:26 AM

Interestingly my test-coverage for the parts of the project I did this way are very high! (At least this what http://www.jetbrains.com/dotcover/ tells me :-) ) If I subtract the pending tests i am at a surprisingly 100% coverage.

I believe the reason is, that the BDD style enables different types of the tests levels for the same story. Stories do contain integration-tests, programmers tests and unit tests, side by side!

Jul 19, 2010 at 3:25 PM

Hi guys,

I've been running a small project using StoryQ called Mastermind; it's on Codeplex. The project was to let me learn BDD and to see how it fits in with Agiles user stories.

First off StoryQ is excellent Rob, it works really well and it's fluent design is brilliant.  It really compliments user stories as a testable specifications; I like it!

Mastermind takes the BDD approach I described before; the outer loop for the stories, dropping down into an inner loop for unit testing. What I found is doing this approach felt a lot like duplicate effort but.. I found that point of view was important. The story tests covered the users point of view; the behaviour needed by the user. There were less mocks needed and these were really for mocking out user interactions (the console output and input) and some random things. The drop down into the unit testing felt like the developers point of view, it was about driving out the design. There were a lot more mocks and stubs.

Anyway Robert if you find using only storyq for testing works well then go for it; not going to tell you your job. The example stories you have posted are easy enough to read and yeah code reuse in each scenario. Why not? yeah I have changed my tune from before because Rob was right code reuse in StoryQ is easier than I had thought.

Have a look at Mastermind if you like... it's not finished... but tell me what you think of that approach. I'm up for a review so be as nice as you like ;)

http://mastermind.codeplex.com