NBehave

NEW POST: RhinoMocks and Stories

simone_b — Mon, 12 May 2008 07:10:19 GMT

Fine, it's already up on Google hosting, along with this other one that I had already submitted.

jbogard wrote:
Hey Simone,

We definitely accept patches, but just not through CodePlex. We've written off CodePlex as a source control system :)

Would you mind re-submitting that patch, just with the SVN diff in a zip file in an email? That'll be the easiest for us. CodePlex patching is....interesting to say the least.

Thanks for the interest,

Jimmy

NEW POST: RhinoMocks and Stories

jbogard — Sun, 11 May 2008 16:24:02 GMT

Hey Simone,

We definitely accept patches, but just not through CodePlex. We've written off CodePlex as a source control system :)

Would you mind re-submitting that patch, just with the SVN diff in a zip file in an email? That'll be the easiest for us. CodePlex patching is....interesting to say the least.

Thanks for the interest,

Jimmy

NEW POST: RhinoMocks and Stories

simone_b — Sun, 11 May 2008 10:40:56 GMT

Are you planning to review submitted patches or accept any contributions? If so, I'd be glad to do it - as I did already - otherwise please be more explicit in saying that you don't accept any contributions.

NEW POST: RhinoMocks and Stories

jbogard — Sun, 11 May 2008 03:31:04 GMT

Hey Simone,

Right now we don't have any coupling between the mocking framework and the scenarios. It's definitely something we'll look at for the 0.5 release!

simone_b wrote:
Hi guys, this is a great project, I would like to see it grow and contribute if I ever have some time to. I tried it in a small application and would like to know if there's any integration between the story framework and the SpecBase class, where the AutoMockingCOntainer is used. In particular, I would like to create expectations while writing stories, and so far I have only been able to do it by "interrupting" the fluent interface to keep a reference to the story and the using explicitly RecordExpectedBehavior and PlaybackBehavior, as in the snippet below:

var story = new Story("Download and compare two files");
GivenFragment story2;

story.AsA("User").
IWant("to download the two files and compare them").
SoThat("I can resolve the conflict");

using (RecordExpectedBehavior)
story2 = story.WithScenario("The files are identical")
.Given("that the content of the first file is", "a", input => Expect.Call(Get<IFileDownloader>().Download(null)).IgnoreArguments().Return(input))
.And("the the content of the second file is", "a", input => Expect.Call(Get<IFileDownloader>().Download(null)).IgnoreArguments().Return(input));
using (PlaybackBehavior)
story2.When("the files are compared", () => result = helper.Process(new[] ccc))
.Then("the result should be", true, input => Assert.AreEqual(input, result0));

Again, I your approach to BDD a lot, much more than emulating it with usual test fixtures, but I'm missing some documentation a lot.

Patch Uploaded

simone_b — Thu, 17 Apr 2008 22:06:13 GMT

simone_b has uploaded a patch.

Description:
Hi guys, I have been using NBehave extensively in my projects lately and I wanted to upload a patch with some additions and changes which I did to adapt it to my needs.

First, the various xxxSpecBase classes shouldn't have the TestFixture attribute, since I should be able to create an abstract base specification class on top of them and not see my test in the abstract class marked as ignored (I've discussed this with Charlie from NUnit and he said he would contact you about this issue).

Then, I made visible in the SpecBase class the AutomockingContainer Mark<> method, since at times I want to override the default mocking strategy for the components the container creates. I wrote tests to cover this.

Let me know what you think. Anyway, I would like to contribute to the project if you like.

NEW POST: RhinoMocks and Stories

simone_b — Thu, 06 Mar 2008 08:19:58 GMT

Hi guys, this is a great project, I would like to see it grow and contribute if I ever have some time to. I tried it in a small application and would like to know if there's any integration between the story framework and the SpecBase class, where the AutoMockingCOntainer is used. In particular, I would like to create expectations while writing stories, and so far I have only been able to do it by "interrupting" the fluent interface to keep a reference to the story and the using explicitly RecordExpectedBehavior and PlaybackBehavior, as in the snippet below:

var story = new Story("Download and compare two files");
GivenFragment story2;

story.AsA("User").
IWant("to download the two files and compare them").
SoThat("I can resolve the conflict");

using (RecordExpectedBehavior)
story2 = story.WithScenario("The files are identical")
.Given("that the content of the first file is", "a", input => Expect.Call(Get<IFileDownloader>().Download(null)).IgnoreArguments().Return(input))
.And("the the content of the second file is", "a", input => Expect.Call(Get<IFileDownloader>().Download(null)).IgnoreArguments().Return(input));
using (PlaybackBehavior)
story2.When("the files are compared", () => result = helper.Process(new[] ccc))
.Then("the result should be", true, input => Assert.AreEqual(input, result0));

Again, I your approach to BDD a lot, much more than emulating it with usual test fixtures, but I'm missing some documentation a lot.

NEW POST: BDD in Practice

colin_jack — Thu, 28 Feb 2008 21:39:41 GMT

I've been trying to use BDD for a while but I'm having trouble getting my head around it, particularly how you guys use NBehaves stories in practice. So here's my question...

One of the things that most interests me about BDD and NBehave in particular is the idea of having higher level tests that show the overall behavior of a piece of the system. Seeing the discussion at your blog the advantage of defining the stories are:

-> Providing a more complete description of the behavior of the system
-> Unit tests too granular
-> Even specifications can be difficult to organize
-> Stories provide a better overall, macro view of the system

This really attracts me because I think that to get some of the advantages of TDD you need to test at lower levels but if you do this the specifications stop acting as good examples. I find this is especially true if there is a lot of interaction testing involved, A->B->C and there's interaction testing right down to C which also has some state tests. To work out the final behavior of A you've got to put in some serious effort.

So my question is how do you do use the story based tests to raise your understanding?

For example when you're writing the top level story based specifications how thorough do you make them. Do you only cover the most common cases using these stories then leave all the more detailed tests to unit tests or lower level specifications?

I'm coming to my own views on this but you guys are the experts on it so I'd be very interested in your views.

NEW POST: Documentation

bsimser — Thu, 28 Feb 2008 18:40:29 GMT

Cool stuff. Thanks Jimmy.

Joe has a post here with an example of usage:
http://www.lostechies.com/blogs/joe_ocampo/archive/2008/02/26/updates-to-nbehave.aspx

But I find your entry more complete. Thanks!

NEW POST: Documentation

jbogard — Wed, 27 Feb 2008 02:11:29 GMT

bsimser wrote:

ksvanhorn wrote:
Where's the documentation for NBehave? I'll I've been able to find is a single example of writing a spec unswe NBehave.

There are examples here but they don't seem to use the features from the latest build (for example the Story attribute) but it should get you started.

Hi Bil,

Here's the canonical example for 0.3:

http://grabbagoft.blogspot.com/2007/09/authoring-stories-with-nbehave-03.html

We're currently driving towards a 0.4 release, which includes the NSpec merge as well as some other enhancements.

NEW POST: Documentation

bsimser — Tue, 26 Feb 2008 20:31:24 GMT

ksvanhorn wrote:
Where's the documentation for NBehave? I'll I've been able to find is a single example of writing a spec unswe NBehave.

There are examples here but they don't seem to use the features from the latest build (for example the Story attribute) but it should get you started.

Patch Uploaded

joeybeninghove — Wed, 16 Jan 2008 21:15:25 GMT

joeybeninghove has uploaded a patch.

Description:
Just a quick patch to add some generics goodness to the NUnit type extensions.

Thanks,
Joey

Patch Uploaded

joeybeninghove — Wed, 16 Jan 2008 20:21:57 GMT

joeybeninghove has uploaded a patch.

Description:
Ok guys, so after much toiling over getting the patch file generated correctly, here ya go.

Here are some things to note:

* 2 new projects under the NBehave.Runner solution folder (NBehave.NAnt and NBehave.NAnt.Tests)
* I wanted to re-use some of the existing classes that were used only in the console runner so I refactored those out and put them in the Narrator project
o NBehave.Narrator.Framework.EventListeners folder (with various implementations of event listeners)
o NBehave.Narrator.Framework.PlainTextOutput.cs (formerly ConsoleOutput, but refactored to take a TextWriter to invert the dependency on what it writes to)
* After these refactoring I marked the old classes in the console project as Obsolete (pending your review, you can update the references to them and delete them)
* I updated the main NBehave.build script to include the NBehave.NAnt.Tests project when running the test targets
* Oh, I also updated the nunit.framework.dll and Rhino.Mocks.dll assemblies in the lib folder (included in the attached zip file)
o There was an inconsistency between the version of the nunit.framework.dll in the "lib" folder vs. the "tools" folder which is now cleaned up
o Took the liberty to update Rhino Mocks, 'cause I've grown used to the new Expect.Call(delegate { mock.DoSomething(); }) notation which wasn't in the version of Rhino Mocks being used by NBehave... :D

Anywho, attached is a zip file containing the patch file along with the updated assemblies for the lib folder (since those couldn't be included in the patch). I've tested the patch locally against a clean get of the current repository.

So just a couple simple steps should do the trick:

1. Apply the .patch file to the trunk
2. Copy the 2 updated assemblies into the lib folder
3. Run "go test" and all should be good.

Let me know if you have any problems.

Thanks,
Joey

NEW POST: Documentation

ksvanhorn — Tue, 15 Jan 2008 17:00:20 GMT

Where's the documentation for NBehave? I'll I've been able to find is a single example of writing a spec unswe NBehave.

UPDATED WIKI: Home

jbogard — Wed, 09 Jan 2008 15:01:41 GMT

Vision Statement

Based on Dan North's initial vision of rbehave and utilizing the behavioral domain specific language (DSL) of Behavior Driven Design (BDD) we created the NBehave framework. The primary goal of NBehave is a framework for defining and executing application requirement goals. These characterizations are modeled after the Behavioral Driven Design (BDD) terms Story, Scenario, Given, When, Then. Relying on a syntax that is lightweight and targeted at product owners (a few "quotes" mostly), the code becomes an executable and self-describing requirements document. The definitions within the actual unit test of the application coupled with the organic nature of the architecture and ubiquity of the domain model translates these concepts into becoming one cohesive amalgam. With the help of Domain Driven Design, the code actually becomes what we have always wanted, living requirements that are constantly asserted on to ensure their viability and accuracy from inception to implementation. Can you say true traceability!

Note on source control

We have moved our source control to Google Code:

http://nbehave.googlecode.com/svn/trunk/

ONLY source code has moved over, all other project related items (wiki, issue tracker, discussions, releases) are staying on CodePlex. For more details:

http://grabbagoft.blogspot.com/2008/01/nbehave-source-moved-to-google-code.html

Where we are going

We will ensure that NBehave is stable and performant by exercising a test first approach throughout its development.
We are committed to developing a lightweight behavioral API the exposes a flexible Fluent Interface for describing the DSL of behavior driven development.
We are committed that the usage of the DSL will be targeted towards the understanding of product owner or any other stakeholder that assumes the role as business advocate.
We will encourage the use of NBehave with ALL unit testing frameworks.
We will continue to evangelize the use Behavior Driven Development through out the development community.

For more information about behavior-driven design, check out these articles from Dan North's blog:

Content

Features
Examples
Set Up

NEW POST: Any activity?

jbogard — Fri, 04 Jan 2008 18:56:18 GMT

bonder wrote:
Is the project still alive?

We're in the process of moving our source to Google Code, which should make it easier for folks to contribute. Releases, discussions, issues, etc. will still be hosted on CodePlex, but due to a lot of folks requesting SVN, we're moving our source.

That's why it's been a little quiet lately, nobody wanted to commit source if we were about to move it :). We'll post an announcement soon on status/roadmap, etc. once we've completed the source move.

NEW POST: Any activity?

bonder — Fri, 04 Jan 2008 16:45:44 GMT

Is the project still alive?

Source code checked in

jbogard — Mon, 26 Nov 2007 22:11:12 GMT

Converted to VS 2008

NEW POST: Place In The Testing Process

colinjack — Sun, 04 Nov 2007 18:22:20 GMT

One thing I'm noticing is that BDD is being used to mean several different things, and mocking is one part of this. For example my reading on BDD has left me confused whether its best suited to interaction style testing or state based domain style testing of the domain layer. Martin Fowler indicates his understanding is:

"An important offshoot of the mockist style is that of Behavior Driven Development (BDD). BDD was originally developed by my colleague Dan North as a technique to better help people learn Test Driven Development by focusing on how TDD operates as a design technique. This led to renaming tests as behaviors to better explore where TDD helps with thinking about what an object needs to do. BDD takes a mockist approach, but it expands on this, both with its naming styles, and with its desire to integrate analysis within its technique. I won't go into this more here, as the only relevance to this article is that BDD is another variation on TDD that tends to use mockist testing. I'll leave it to you to follow the link for more information."

So my question is how does BDD relate to mocking, especially in the context of a DDD domain model?

NEW POST: Plain Text Stories

bcotton — Wed, 24 Oct 2007 15:13:46 GMT

Have you guys seen what's happening in rBheave land? It would be great to have a .net port of this this:

http://blog.davidchelimsky.net/articles/2007/10/21/story-runner-in-plain-english

And a first cut at an editor:

http://blog.aslakhellesoy.com/2007/10/24/in-browser-editor-for-rspec-stories

Patch Uploaded

makka — Thu, 11 Oct 2007 19:17:50 GMT

makka has uploaded a patch.

Description:
To get this patch working you need to :
Create a post build action that copy NBehave assemblies inside
C:\Program Files\TestDriven.NET 2.0\NBehave\

Create a registry key whit these values :

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\MutantDesign\TestDriven.NET\TestRunners\NBehave]
"Application"="C:\\Program Files\\TestDriven.NET 2.0\\NBehave\\NBehave-Console.exe"
"AssemblyPath"="C:\\Program Files\\TestDriven.NET 2.0\\NBehave\\NBehave.AddIn.dll"
"TargetFrameworkAssemblyName"="NBehave.Framework"
"TypeName"="NBehave.AddIn.NBehaveTestRunner"
@="30"

edit the file TestDriven.dll.config located in %PROGRAMFILE%\TestDriven.NET 2.0 and add some new node

<icon name="NBehave" file="icons\Runtime.bmp"/>
under
<icons> section

<button command="ApplicationNBehave" />
in the same section that contains
<button command="ApplicationMbUnit" />

<command name="ApplicationNBehave" applicationName="NBehave" handler="TestDriven.Services.Commands.GuiApplicationHandler, TestDriven.Services" icon="NBehave" buttonText="NBehave" tooltip="Start NBehave application" />
in the same section that contains
<command name="ApplicationMbUnit" applicationName="MbUnit" handler="TestDriven.Services.Commands.GuiApplicationHandler, TestDriven.Services" icon="MbUnit" buttonText="MbUnit" tooltip="Start MbUnit application" />

Sorry but creating this patch with CodePlexClient is not very easy
If you need to help to apply do not hesitate to contact me using my blog:
http://blogs.ugidotnet.org/makka