Welcome, Latest Changes and Whats Up Next

[Mike Minutillo]

Hey all,

First up, thanks to everyone for their input and help so far. It's
been great to watch a little micro-community come together.

Thanks to patches supplied by @firegrass and @liammclennan we now have
NUnit Output suitable for use in CI situation, a quiet mode, the
capability to add external feature files at runtime and several bug-
fixes. Thanks guys.

As we go I'm trying to clean up the code significantly and once done
I'll open up the repository to a few others so please keep the
contributions coming. This is just so that we can get a cohesive
architecture running that makes it easy to consistently make changes
(much like the CLI parser is set up now).

So far the focus has been on getting up and running with NGourd and
integrating it into peoples development process. If anyone is using it
in anger I'd love to hear about it (I believe that Liam has a CC.NET
setup going and Patrick is running a TeamCity stack with Selenium!).
There's still a few things to do here like tagging and stronger
lifecycle support. There are two other areas of key focus:

1) Tests (or Specifications). People fail to take a testing tool
seriously if it isn't itself tested. Ideally I'd like to do this
NGourd but I think that some of the more advanced features of the
scenario language could be very helpful here (I'm thinking of
multiline and table parameters and scenario outlines).

2) Core language functionality like multi-line and table parameters
and scenario outlines :) So far I've been borrowing (stealing) ideas
from Cucumber but keeping my eyes open for areas that we can take
advantage of the capabilities of .NET. I want to look at the Cucumber
interpreter as well because it's possible that we could just borrow
that and run it in IronRuby

I've tried to add things to the Google Code Issues list as they occur
to me so feel free to add stuff there. If a feature-request or bug
requires discussion we'll do it here.

Lastly, I've sent in a request to open the project up for Mercurial
support. I'm only new at Mercurial but I really like the idea of using
a DCVS and I'd like to mess with it in practice.

Anyway, that's it for now. I had a few specific questions but I might
come back to them when I'm sitting in front of Visual Studio ready to
make changes.

Thanks again for the support so far.

P.S. If you are looking for a project to test NGourd out on then I'm
sure that Jonathan Parker would appreciate specs for MindMelder
http://code.google.com/p/mindmelder/

[Liam McLennan]

Im using NGourd for functional testing of one of my projects. I currently have 4 features, 5 scenarios and 23 steps. Already it is a useful tool and I am looking forward to new features and improvements. Integration is something that seems important to me so as I get time I will probably look at writing a proper teamcity plugin and integrating with TestDriven.Net.

I have no experience with cucumber so I am still trying to find the best patterns to use. At the moment I have one Steps file per feature, containing one Steps class per scenario. I think that each scenario should have its own class so that it can build private state. Cucumber / NGourd work best for functional tests, so I think that projects will always need another test framework for unit tests. For this reason I would like to see the assertions taken out of NGourd. At the moment I am prefixing all of my assertions to avoid using the built in assertions.

One feature that I am missing is the ability to ignore scenarios. It is natural to write all of the scenarios for a feature at once, before the code is written. Without the ability to ignore this causes the build to fail until the entire feature has been implemented.

I am interested to hear other people's opinions of how this tool should be used.

Liam.

--
Liam McLennan.

li...@eclipsewebsolutions.com.au
http://www.eclipsewebsolutions.com.au

[Michael Minutillo]

Yeah I'm new to the field as well. Interestingly the Cucumber community regards the one steps file per feature to be an anti-pattern (http://wiki.github.com/aslakhellesoy/cucumber/feature-coupled-steps-antipattern ) . I believe this is because the steps should align with application boundaries whereas features should align with domain boundaries. A classic example would be to have steps that interact with the database and steps that automate a browser window. Both would be useful for any particular feature and should be somewhat re-usable. That is the point of the Before and After steps so that each steps container can maintain it's own state on a scenario by scenario basis.

I'm of two minds with the Assertions. I can definitely see the point that people will want to bring their own but I wanted people to be able to get up and running with NGourd without using a 3rd party Unit Testing tool. I hadn't thought about the fact that Assert in NGourd would clash with Assert in the other frameworks. I might get rid of these and put a Fail(string message) on the Base Container and then recommend other tools for those who need more. Also would an Assert(bool, string) method on the base class clash with the Assert class in the other frameworks? I don't think it would but I need to check.

The feature to ignore scenarios is something I'd thought of. I think the best way to deal with this would be to add a command line switch to allow users to determine what breaks the build (i.e. Only failures, all non-passing steps, nothing). That would allow folks to better control the integration. We might set it up so that any scenario with A missing step is skipped (another flag?). That should ensure that scenarios will only run if they are complete and expected to work. 

--
Michael M. Minutillo
Indiscriminate Information Sponge
Blog: http://wolfbyte-net.blogspot.com

[Liam McLennan]

How would you implement the GSTCalculator example? The OrderSteps class has a field 'order' that is used to maintain state between steps, so none of the steps can be reused independantly. Even that cucumber example is using private variables, so the steps can't be reused independantly.

A command line switch would be sufficient to solve the not implemented scenario problem.

[Michael Minutillo]

The internal state of the step containers is really short-hand for what is going on inside the application. 

Steps in a container shouldn't be used in isolation of each other but the unit of re-use shouldn't be a single feature either. The GSTCalculator sample is actually wrong. It should still be using the private variable but there should be an After step in there to clear that variable. This forces the feature writer to build up the state (in Given steps). A more robust approach is to change the system to recreate the necessary step containers for each scenario (I like this idea but depends on speed). This would effectively kill off any non-static state for the containers in between each scenario again forcing the Scenario writer to indicate state.

State is what BDD is all about (at least to me). Given the system is some state, When some event occurs, Then the system should be in a new state.

Given steps should be about setting state up (I think verifying expected state is a good idea here as well)

Then steps should be about verifying state

And the When steps should be about messing with the system in a way that alters the state.

In the case where you are specifying only a small part of the system (like in the GSTCalculator sample) then you need to maintain that state in the steps container. Were we dealing with a much larger chunk of system, the system itself would do that for us. This is what I was talking about on twitter when I mentioned that Context might be a useful thing to have here. Each scenario should have it's own context which determines initial state and maintains state between steps to allow for contextual reading of steps. Otherwise context needs to be established between each step.

Scenario:

  Given I have a new order called "new order"

  When I add 2 apples worth $5 to the order called "new order"

  Then I the value of order "new order" should be $10

Even that doesn't work because you need to maintain the a dictionary of orders. For now storing contextual state directly into the steps container seems like the easiest solution.

[Liam McLennan]

Since every step depends upon context established by previous steps the other possibility is to have each step pass its state to the next step.

Tests against UIs (cucumber uses webrat) dont have this problem because the state is maintained by webrat and the web server.

[Patrick McEvoy]

I'm using NGourd to run our selenium tests. To me this makes a lot of
sense and fits the BDD way of thinking. I use hudson, nant, nunit,
ngourd and mono on debian.

Completely agree with needing tests, chicken-egg problem will go in
time. However I agree with Liam that both unit and functional/feature
testing is required.

I like the command line switch idea re. ignore scenarios

I am a beginner too... but as I understand it the whole point is that
there is no isolation between steps so that reuse is easy.

The only point I'd like to raise is state-aware 'per scenario' Before
and After hooks. So, for example, when a step fails I get a screenshot
taken (using selenium) in the After hook. For this NGourd could do
with some kind of context in StepContainerBase and I'm sure that would
be useful for other things too. What do people think? Does anyone else
want/need this?

Also big thanks to Michael and Liam :)

On May 19, 2:46 am, Mike Minutillo <michael.minuti...@gmail.com>
wrote: