This project is read-only.

Text plain scenarios and Resharper

Jan 22, 2010 at 11:41 AM


Is there any way to run NBehave text plain scenarios with resharper (gallio plug-in) instead of nbehave-console ? I don't use fluent syntax but Given/When/Than attributes.



Jan 24, 2010 at 8:24 PM

Unfortunately there isn't a runner for resharper, at least not that I know of.

Apr 19, 2010 at 7:59 AM

Shouldn't this just work with ReSharper's built in NUnit test runner (when using NBehave.Spec.NUint), the test runner plugin (when using NBehave.Spec.xUnit) or the Gallio test runner plugin (when using NUint, xUnit or MbUnit)?

That said, it doesn't for me (at least not in the couple of configurations that I've tried so far). Anybody got this working?

Apr 19, 2010 at 8:22 PM

As weird as it may sound :) , there's no connection between the spec parts in nbehave with the narrator stuff.

Someone needs to implement a R# runner for the text parts in nbehave, or integrate with NUnit, xunit, MbUnit to get the functionality you want.

Apr 27, 2010 at 5:05 PM

I note that Reshaper detects mbUnit and if you look at the full test report, you get a Gallio report.

Jun 22, 2011 at 8:41 AM

I've uploaded a patch with NBehave.Embedded project which allows to write and execute plain text scenario within any kind of xUnit framework family.

It's also possible to specify used ActionSteps classes for each scenario separatelly as a parameter for Execute method

The spec example:

[TestFixture, ActionSteps]

public class WhenClassWithTextScenarioHasEmbeddedActionSteps



public void ShouldRecognizeEmbeddedActionSteps()


@"Given something

     When happens something

    Then profit".Execute();



[When("happens something")]


public void StepImplementation()




Jun 22, 2011 at 9:07 PM

Cool, we will look at it.

Jun 29, 2011 at 12:52 PM

I used your patch as inspiration an built a feature that let you run feature files from any testframework.

Make sure you mark the feature files to be copied to output folder


    public class Features
        public void Passing_Feature()

        public void Failing_Feature()

Its implemented in the compositedesign branch

Jun 29, 2011 at 12:52 PM

There is a crude R# runner too.

Jun 29, 2011 at 1:07 PM

Though I can't find it among the branch's commits yet, this is fine with me.

I have only one note: there is a special feature which was implemented to simplify specification development with a huge codebase.

I am talking about this syntax:


When we made possible to specify action steps explicitly, it speeded up our development and made possible to run the same scenarios with different action steps implementation (we used this feature to run our specs with both integration and unit test environments).

Don't miss it, please! :)

Jun 29, 2011 at 1:33 PM

The code is there, at least now ;-) see this revision

I'm curious, why would you want to run the same scenario with different implementations of steps? Isnt that just another scenario?

Jun 29, 2011 at 1:53 PM
Edited Jun 29, 2011 at 9:48 PM

The reason is simple: integration test run takes a lot more time to execute.

Speaking honestly, we don't often use this feature.

One of the real scenarios is:

Scenario: should show people action for not admin user when user allow acces to people area

Given permission people access is enabled for 'Developer' role

And  project 'Project1' with process 'All Practices' created

And user 'vasya' is in 'Developer' role

And user 'vasya' is a project 'Project1' project member

And user 'vasya' is not an administrator

And user 'vasya' is logged in

When project 'Project1' selected as project context

Then 'Home' action group should contain the actions: Yesterday, Projects, Programs, People, Import, Teams Board Beta

This scenario is for navigation system which is quite sophisticated in our project, so we have plenty of tests which cover this are functionality.

In the most cases our developers use Execute(In.Context) syntax to be sure that their code use definite action steps implementation because sometimes Given/When/Then actions can have slightly different meaning in different scenarios.

Also it solves action step navigation issue when a developer can't find which action step definition used -- we've got hundreds actions steps at the moment.

BTW, do you think if it's possible to introduce extra-tracing feature in NBehave? This trace could contain runtime execution information - where action step is actually located.

It could save our time in some cases.

Jun 29, 2011 at 2:36 PM

I will add some tracing ability to nbehave. I think its on the backlog.

Its cool that you use the same scenario in different environments (didnt read your other reply very well, sorry).
So could it have been possible for you to have had 2 projects/assemblies, one with the integration steps and one with unit test steps and linking in the feature files from one projekt to the other?
It wouldnt solve the problem with similar steps, maybe you could have solved that by implementing the IMatchFiles interface on the ActionSteps classes?

Jun 29, 2011 at 9:59 PM

I am not familiar with this interface, sorry.

Anyway, we do not use external specs.

My intention was not to introduce too many changes into development process, so that's why the approach with embedded BDD specs was implemented.

Then I explained to my team how to use BDD-style in their day-by-day development with just minor changes, and finally almost all our team members can easily write BDD specs.

They can also debug failed spec exactly the same way as they used to do when they were written unit tests.

This is the great achievement and I am going to keep it :)

Jul 8, 2011 at 7:58 PM

Of course you should keep it!

I have committed code so you can run text just as in your patch, the only difference is the name of the extension method, its called ExecuteText.

Jul 8, 2011 at 10:18 PM


Hope that this feature will be useful for some people! :)