OK, I just want to use something that isn't a dead project and helps
me find a good shared language with my customer. I have been using my
own name styling and extnesion methods for clean asserts for awhile.
Does anyone have a large regression suite in any of these? Does anyone
have experience woth more than one? I really want to hear
recomendations from others experience so I can avoid your pain. Help a
brutha out?
On Tue, Apr 14, 2009 at 10:32 PM, David Starr <da...@elegantcode.com> wrote:
> OK, I just want to use something that isn't a dead project and helps
> me find a good shared language with my customer. I have been using my
> own name styling and extnesion methods for clean asserts for awhile.
> Does anyone have a large regression suite in any of these? Does anyone
> have experience woth more than one? I really want to hear
> recomendations from others experience so I can avoid your pain. Help a
> brutha out?
> On Tue, Apr 14, 2009 at 10:32 PM, David Starr <da...@elegantcode.com>wrote:
>> OK, I just want to use something that isn't a dead project and helps
>> me find a good shared language with my customer. I have been using my
>> own name styling and extnesion methods for clean asserts for awhile.
>> Does anyone have a large regression suite in any of these? Does anyone
>> have experience woth more than one? I really want to hear
>> recomendations from others experience so I can avoid your pain. Help a
>> brutha out?
On Tue, Apr 14, 2009 at 10:46 PM, David Starr <da...@elegantcode.com> wrote:
> I actually read Aaron's post on it (again) earlier tonight. That's the
> thing, this is worse than picking an IoC container :)
> C'mon, Jimmy, what are you using?
> David Starr
> elegantcode.com | pluralsight.com
> On Tue, Apr 14, 2009 at 9:35 PM, Jimmy Bogard <jimmy.bog...@gmail.com>wrote:
>> Don't forget about MSpec!
>> On Tue, Apr 14, 2009 at 10:32 PM, David Starr <da...@elegantcode.com>wrote:
>>> OK, I just want to use something that isn't a dead project and helps
>>> me find a good shared language with my customer. I have been using my
>>> own name styling and extnesion methods for clean asserts for awhile.
>>> Does anyone have a large regression suite in any of these? Does anyone
>>> have experience woth more than one? I really want to hear
>>> recomendations from others experience so I can avoid your pain. Help a
>>> brutha out?
OK, so you just aren't updating the downloads? The downloads are stale, but
code is fresh? Right on! I just saw that my ElegantCode tribe member Chris
Bilson is a contrib on MSpec, though. Might have to go there, too.
David Starr
elegantcode.com | pluralsight.com
On Tue, Apr 14, 2009 at 9:49 PM, Jimmy Bogard <jimmy.bog...@gmail.com>wrote:
> Well, NBehave, naturally! It's been doing what we need for awhile, so we
> just make trunk commits as needed.
> On Tue, Apr 14, 2009 at 10:46 PM, David Starr <da...@elegantcode.com>wrote:
>> I actually read Aaron's post on it (again) earlier tonight. That's the
>> thing, this is worse than picking an IoC container :)
>> C'mon, Jimmy, what are you using?
>> David Starr
>> elegantcode.com | pluralsight.com
>> On Tue, Apr 14, 2009 at 9:35 PM, Jimmy Bogard <jimmy.bog...@gmail.com>wrote:
>>> Don't forget about MSpec!
>>> On Tue, Apr 14, 2009 at 10:32 PM, David Starr <da...@elegantcode.com>wrote:
>>>> OK, I just want to use something that isn't a dead project and helps
>>>> me find a good shared language with my customer. I have been using my
>>>> own name styling and extnesion methods for clean asserts for awhile.
>>>> Does anyone have a large regression suite in any of these? Does anyone
>>>> have experience woth more than one? I really want to hear
>>>> recomendations from others experience so I can avoid your pain. Help a
>>>> brutha out?
David, you said you are looking for getting a good shared language with your
customer. That's a cognitive practice that a framework can't help you
with. Your efforts are best geared towards gaining understanding, then
choosing a dsl to help your organize that understanding in your code, once
you are able to articulate it accurately and effectively. A dsl framework
cannot help you with that. Spend a good 5 or 6 months practicing, then
choose a dsl later that fits your newfound knowledge.
Ray Lewallen
On Apr 14, 2009 10:32 PM, "David Starr" <da...@elegantcode.com> wrote:
OK, I just want to use something that isn't a dead project and helps
me find a good shared language with my customer. I have been using my
own name styling and extnesion methods for clean asserts for awhile.
Does anyone have a large regression suite in any of these? Does anyone
have experience woth more than one? I really want to hear
recomendations from others experience so I can avoid your pain. Help a
brutha out?
On Wed, Apr 15, 2009 at 5:53 AM, David Starr <da...@elegantcode.com> wrote:
> OK, so you just aren't updating the downloads? The downloads are stale, but
> code is fresh? Right on! I just saw that my ElegantCode tribe member Chris
> Bilson is a contrib on MSpec, though. Might have to go there, too.
> David Starr
> elegantcode.com | pluralsight.com
> On Tue, Apr 14, 2009 at 9:49 PM, Jimmy Bogard <jimmy.bog...@gmail.com>wrote:
>> Well, NBehave, naturally! It's been doing what we need for awhile, so we
>> just make trunk commits as needed.
>> On Tue, Apr 14, 2009 at 10:46 PM, David Starr <da...@elegantcode.com>wrote:
>>> I actually read Aaron's post on it (again) earlier tonight. That's the
>>> thing, this is worse than picking an IoC container :)
>>> C'mon, Jimmy, what are you using?
>>> David Starr
>>> elegantcode.com | pluralsight.com
>>> On Tue, Apr 14, 2009 at 9:35 PM, Jimmy Bogard <jimmy.bog...@gmail.com>wrote:
>>>> Don't forget about MSpec!
>>>> On Tue, Apr 14, 2009 at 10:32 PM, David Starr <da...@elegantcode.com>wrote:
>>>>> OK, I just want to use something that isn't a dead project and helps
>>>>> me find a good shared language with my customer. I have been using my
>>>>> own name styling and extnesion methods for clean asserts for awhile.
>>>>> Does anyone have a large regression suite in any of these? Does anyone
>>>>> have experience woth more than one? I really want to hear
>>>>> recomendations from others experience so I can avoid your pain. Help a
>>>>> brutha out?
TeamCity has a guestAuth switch that you can add to a URL (as the
first dir after the domain) that let's you browse as the guest user.
I'm on my phone right now so I can't check if it'd work for your URL
but it definitely works for the file urls, I use them for the fluent
nh build downloads.
On Wednesday, April 15, 2009, Morgan Persson <lazy...@gmail.com> wrote:
> We haven't updated the downloads in a long time, we should...
> It's a pity that http://teamcity.codebetter.com/project.html?projectId=project30 requires a login, the latest build is available there.
> /Morgan
> On Wed, Apr 15, 2009 at 5:53 AM, David Starr <da...@elegantcode.com> wrote:
> OK, so you just aren't updating the downloads? The downloads are stale, but code is fresh? Right on! I just saw that my ElegantCode tribe member Chris Bilson is a contrib on MSpec, though. Might have to go there, too.
> David Starr
> elegantcode.com | pluralsight.com
> On Tue, Apr 14, 2009 at 9:49 PM, Jimmy Bogard <jimmy.bog...@gmail.com> wrote:
> Well, NBehave, naturally! It's been doing what we need for awhile, so we just make trunk commits as needed.
> On Tue, Apr 14, 2009 at 10:46 PM, David Starr <da...@elegantcode.com> wrote:
> I actually read Aaron's post on it (again) earlier tonight. That's the thing, this is worse than picking an IoC container :)
> C'mon, Jimmy, what are you using?
> David Starr
> elegantcode.com | pluralsight.com
> On Tue, Apr 14, 2009 at 9:35 PM, Jimmy Bogard <jimmy.bog...@gmail.com> wrote:
> Don't forget about MSpec!
> On Tue, Apr 14, 2009 at 10:32 PM, David Starr <da...@elegantcode.com> wrote:
> OK, I just want to use something that isn't a dead project and helps
> me find a good shared language with my customer. I have been using my
> own name styling and extnesion methods for clean asserts for awhile.
> Does anyone have a large regression suite in any of these? Does anyone
> have experience woth more than one? I really want to hear
> recomendations from others experience so I can avoid your pain. Help a
> brutha out?
On Wed, Apr 15, 2009 at 5:34 AM, Raymond Lewallen <rlewal...@gmail.com>wrote:
> David, you said you are looking for getting a good shared language with > your customer. That's a cognitive practice that a framework can't help you > with. Your efforts are best geared towards gaining understanding, then > choosing a dsl to help your organize that understanding in your code, once > you are able to articulate it accurately and effectively. A dsl framework > cannot help you with that. Spend a good 5 or 6 months practicing, then > choose a dsl later that fits your newfound knowledge.
> Ray Lewallen
Amen to this. It seems most people coming into BDD focus on the tools rather than the practice far too early. Wise words.
> On Wed, Apr 15, 2009 at 5:34 AM, Raymond Lewallen <rlewal...@gmail.com>wrote:
>> David, you said you are looking for getting a good shared language with
>> your customer. That's a cognitive practice that a framework can't help you
>> with. Your efforts are best geared towards gaining understanding, then
>> choosing a dsl to help your organize that understanding in your code, once
>> you are able to articulate it accurately and effectively. A dsl framework
>> cannot help you with that. Spend a good 5 or 6 months practicing, then
>> choose a dsl later that fits your newfound knowledge.
>> Ray Lewallen
> Amen to this. It seems most people coming into BDD focus on the tools
> rather than the practice far too early. Wise words.
On Wed, Apr 15, 2009 at 8:05 AM, David Starr <da...@elegantcode.com> wrote:
> I hear and get that, guys. I have been using the structure and discussion
> for awhile. I probably wasn't careful enough when describing things above.
> What I am really after here is tooling to support the existing discussion.
> David Starr
> elegantcode.com | pluralsight.com
> On Wed, Apr 15, 2009 at 3:21 AM, Ben Lovell <benjamin.lov...@gmail.com>wrote:
>> On Wed, Apr 15, 2009 at 5:34 AM, Raymond Lewallen <rlewal...@gmail.com>wrote:
>>> David, you said you are looking for getting a good shared language with
>>> your customer. That's a cognitive practice that a framework can't help you
>>> with. Your efforts are best geared towards gaining understanding, then
>>> choosing a dsl to help your organize that understanding in your code, once
>>> you are able to articulate it accurately and effectively. A dsl framework
>>> cannot help you with that. Spend a good 5 or 6 months practicing, then
>>> choose a dsl later that fits your newfound knowledge.
>>> Ray Lewallen
>> Amen to this. It seems most people coming into BDD focus on the tools
>> rather than the practice far too early. Wise words.
nBehave looks good, but I can't find any documentation?
SpecUnit.NET is in the lead for me right now.
I just looked at specter, which looks interesting, but I'm not so
sure. I don't know how well that'd work in Visual Studio?
I just don't like the syntax of MSpec.
The thing with nBehave and SpecUnit.NET is that I hate all those
underscores. C# has the convention of using camel case, and I'd just
rather stick with that.
I'm almost to the point of just using nUnit and having a naming
convention for the tests.
I've been watching this thread with interest. You ask a reasonable question,
and I'm not sure I have an answer for you.
The problem I am seeing in the .NET space is that people keep producing
Little Languages or frameworks just because they can - not necessarily
because the framework is useful - or because they want to demonstrate their
dot-net-fu.
JBehave and cucumber (the rspec scenario runner) work because of what they *
don't* have. They simply map a line from a text file (starting with "Given",
"When" or "Then") to an annotated method or block of code, possibly with
parameters. That's it. That's all they do. In fact they both use other
frameworks (JUnit and RSpec, respectively) to execute the scenarios.
BDD works at two levels. At the outermost level it is analagous to automated
acceptance testing - each scenario represents an acceptance test. It is
quite likely you will want to reuse steps from one acceptance test in
another. In fact the point of scenarios is to perform the same event (the
When step) in different contexts (different combinations of Givens) and to
expect different outcomes (the Thens). This is where a BDD framework can be
useful.
At the code level BDD is coding-by-example (aka TDD), where you don't care
so much about reuse of steps. Each example (or unit test in TDD-speak)
demonstrates a specific aspect of the behaviour of an object, or its
interactions with other objects, at a detail level.
It seems that all the .NET "BDD frameworks" are focused on this lower level
- where tools like NUnit are already perfectly adequate and where they are
almost always overkill. This means there isn't anything analagous to JBehave
or cucumber - a plain text scenario runner with reusable steps - in .NET.
I would love to see NBehave become a port of JBehave but taking advantage of
C# semantics and language features. Right now there is a bunch of
fragmentation in the .NET space. I haven't even heard of half these
frameworks, which is a shame because I'd be happy to correspond with their
authors. I have shared this vision with Morgan Persson and Joe Ocampo (the
NBehave guys) and I am confident they are going in the right direction, but
I haven't been in touch with any of the others.
Whatever they are promoting it isn't anything I would call BDD. The point of
BDD is to bring business stakeholders, analysts, testers and programmers
together to describe application behaviour in a consistent and useful way.
This splintering of frameworks, syntax-fu and not-invented-here syndrome is
the antithesis of that.
It would be great to see some cohesion across the various frameworks to
create a robust BDD scenario runner for .NET. That would make me very happy.
> nBehave looks good, but I can't find any documentation?
> SpecUnit.NET is in the lead for me right now.
> I just looked at specter, which looks interesting, but I'm not so
> sure. I don't know how well that'd work in Visual Studio?
> I just don't like the syntax of MSpec.
> The thing with nBehave and SpecUnit.NET is that I hate all those
> underscores. C# has the convention of using camel case, and I'd just
> rather stick with that.
> I'm almost to the point of just using nUnit and having a naming
> convention for the tests.
Regarding Cucumber on IronRuby; it's very immature as of now. The
latest version of Cucumber doesn't run on IronRuby 0.3 (or 0.2 for
that matter).
If you are interested to try it out, I recently got Cucumber 0.1.16
running together with rspec 1.1.12 (IIRC) on IronRuby 0.3, a setup
which I'll demo speccing ASPNET MVC controllers at the ALT.NET Oresund
meeting in Malmö, Sweden, today. I plan to blog about it later this
week.
On Mon, Apr 27, 2009 at 2:55 AM, Dan North <tasta...@gmail.com> wrote:
> Hi David.
> I've been watching this thread with interest. You ask a reasonable question,
> and I'm not sure I have an answer for you.
> The problem I am seeing in the .NET space is that people keep producing
> Little Languages or frameworks just because they can - not necessarily
> because the framework is useful - or because they want to demonstrate their
> dot-net-fu.
> JBehave and cucumber (the rspec scenario runner) work because of what they
> don't have. They simply map a line from a text file (starting with "Given",
> "When" or "Then") to an annotated method or block of code, possibly with
> parameters. That's it. That's all they do. In fact they both use other
> frameworks (JUnit and RSpec, respectively) to execute the scenarios.
> BDD works at two levels. At the outermost level it is analagous to automated
> acceptance testing - each scenario represents an acceptance test. It is
> quite likely you will want to reuse steps from one acceptance test in
> another. In fact the point of scenarios is to perform the same event (the
> When step) in different contexts (different combinations of Givens) and to
> expect different outcomes (the Thens). This is where a BDD framework can be
> useful.
> At the code level BDD is coding-by-example (aka TDD), where you don't care
> so much about reuse of steps. Each example (or unit test in TDD-speak)
> demonstrates a specific aspect of the behaviour of an object, or its
> interactions with other objects, at a detail level.
> It seems that all the .NET "BDD frameworks" are focused on this lower level
> - where tools like NUnit are already perfectly adequate and where they are
> almost always overkill. This means there isn't anything analagous to JBehave
> or cucumber - a plain text scenario runner with reusable steps - in .NET.
> I would love to see NBehave become a port of JBehave but taking advantage of
> C# semantics and language features. Right now there is a bunch of
> fragmentation in the .NET space. I haven't even heard of half these
> frameworks, which is a shame because I'd be happy to correspond with their
> authors. I have shared this vision with Morgan Persson and Joe Ocampo (the
> NBehave guys) and I am confident they are going in the right direction, but
> I haven't been in touch with any of the others.
> Whatever they are promoting it isn't anything I would call BDD. The point of
> BDD is to bring business stakeholders, analysts, testers and programmers
> together to describe application behaviour in a consistent and useful way.
> This splintering of frameworks, syntax-fu and not-invented-here syndrome is
> the antithesis of that.
> It would be great to see some cohesion across the various frameworks to
> create a robust BDD scenario runner for .NET. That would make me very happy.
> Cheers,
> Dan
> ps. In the meantime I would keep an eye on cucumber on iron ruby. It isn't
> very mature yet but some people are trying it already.
>> nBehave looks good, but I can't find any documentation?
>> SpecUnit.NET is in the lead for me right now.
>> I just looked at specter, which looks interesting, but I'm not so
>> sure. I don't know how well that'd work in Visual Studio?
>> I just don't like the syntax of MSpec.
>> The thing with nBehave and SpecUnit.NET is that I hate all those
>> underscores. C# has the convention of using camel case, and I'd just
>> rather stick with that.
>> I'm almost to the point of just using nUnit and having a naming
>> convention for the tests.
Hi
just a note, NBehave has support for mapping a line of text in a text file
to an annotated method (method with attribute in .net), its not released yet
and currently supports rather simple stuff. For example, you cant do
JBehabe's tic-tac-toe example, but I'm working on it.
Then you can run it from the command line with "nbehave-console.exe
TestPlainTextAssembly.dll /sf=GreetingSystem.txt (if you grab the fix I just
checked in ;)
No support for this feature in msbuild or nant yet. (Anyone want to send me
a patch for this?)
On Mon, Apr 27, 2009 at 2:55 AM, Dan North <tasta...@gmail.com> wrote:
> Hi David.
> I've been watching this thread with interest. You ask a reasonable
> question, and I'm not sure I have an answer for you.
> The problem I am seeing in the .NET space is that people keep producing
> Little Languages or frameworks just because they can - not necessarily
> because the framework is useful - or because they want to demonstrate their
> dot-net-fu.
> JBehave and cucumber (the rspec scenario runner) work because of what they
> *don't* have. They simply map a line from a text file (starting with
> "Given", "When" or "Then") to an annotated method or block of code, possibly
> with parameters. That's it. That's all they do. In fact they both use other
> frameworks (JUnit and RSpec, respectively) to execute the scenarios.
> BDD works at two levels. At the outermost level it is analagous to
> automated acceptance testing - each scenario represents an acceptance test.
> It is quite likely you will want to reuse steps from one acceptance test in
> another. In fact the point of scenarios is to perform the same event (the
> When step) in different contexts (different combinations of Givens) and to
> expect different outcomes (the Thens). This is where a BDD framework can be
> useful.
> At the code level BDD is coding-by-example (aka TDD), where you don't care
> so much about reuse of steps. Each example (or unit test in TDD-speak)
> demonstrates a specific aspect of the behaviour of an object, or its
> interactions with other objects, at a detail level.
> It seems that all the .NET "BDD frameworks" are focused on this lower level
> - where tools like NUnit are already perfectly adequate and where they are
> almost always overkill. This means there isn't anything analagous to JBehave
> or cucumber - a plain text scenario runner with reusable steps - in .NET.
> I would love to see NBehave become a port of JBehave but taking advantage
> of C# semantics and language features. Right now there is a bunch of
> fragmentation in the .NET space. I haven't even heard of half these
> frameworks, which is a shame because I'd be happy to correspond with their
> authors. I have shared this vision with Morgan Persson and Joe Ocampo (the
> NBehave guys) and I am confident they are going in the right direction, but
> I haven't been in touch with any of the others.
> Whatever they are promoting it isn't anything I would call BDD. The point
> of BDD is to bring business stakeholders, analysts, testers and programmers
> together to describe application behaviour in a consistent and useful way.
> This splintering of frameworks, syntax-fu and not-invented-here syndrome is
> the antithesis of that.
> It would be great to see some cohesion across the various frameworks to
> create a robust BDD scenario runner for .NET. That would make me very happy.
>> nBehave looks good, but I can't find any documentation?
>> SpecUnit.NET is in the lead for me right now.
>> I just looked at specter, which looks interesting, but I'm not so
>> sure. I don't know how well that'd work in Visual Studio?
>> I just don't like the syntax of MSpec.
>> The thing with nBehave and SpecUnit.NET is that I hate all those
>> underscores. C# has the convention of using camel case, and I'd just
>> rather stick with that.
>> I'm almost to the point of just using nUnit and having a naming
>> convention for the tests.
I've worked on a few projects where the technology used for system
specification was not the same as that used to implement the system
under test. It's an excellent application of a dynamic language.
When building a web application (.net, java or otherwise) my
preference would be to use ruby: cucumber + webrat + mechanize/
selenium. The act of using different language makes the context shift
between reading your application code and specification code much
cleaner - just as you know what part of the application you're dealing
with when looking at some SQL or javascript.
It also means that there's a lower barrier to entry for QAs and BAs to
actually writing the features and scenarios as they don't need to be
overwhelmed by an IDE.
Testing a wpf or winforms application is a bit more challenging
although it should (theoretically) be possible to build an ironruby
wrapper around something like white.
Clearly you need to use .net tools for unit and integration testing
but an external DSL such as cucumber makes the most sense to me for
specifying overall system behaviour.
Mark.
On Apr 27, 10:55 am, Dan North <tasta...@gmail.com> wrote:
> I've been watching this thread with interest. You ask a reasonable question,
> and I'm not sure I have an answer for you.
> The problem I am seeing in the .NET space is that people keep producing
> Little Languages or frameworks just because they can - not necessarily
> because the framework is useful - or because they want to demonstrate their
> dot-net-fu.
> JBehave and cucumber (the rspec scenario runner) work because of what they *
> don't* have. They simply map a line from a text file (starting with "Given",
> "When" or "Then") to an annotated method or block of code, possibly with
> parameters. That's it. That's all they do. In fact they both use other
> frameworks (JUnit and RSpec, respectively) to execute the scenarios.
> BDD works at two levels. At the outermost level it is analagous to automated
> acceptance testing - each scenario represents an acceptance test. It is
> quite likely you will want to reuse steps from one acceptance test in
> another. In fact the point of scenarios is to perform the same event (the
> When step) in different contexts (different combinations of Givens) and to
> expect different outcomes (the Thens). This is where a BDD framework can be
> useful.
> At the code level BDD is coding-by-example (aka TDD), where you don't care
> so much about reuse of steps. Each example (or unit test in TDD-speak)
> demonstrates a specific aspect of the behaviour of an object, or its
> interactions with other objects, at a detail level.
> It seems that all the .NET "BDD frameworks" are focused on this lower level
> - where tools like NUnit are already perfectly adequate and where they are
> almost always overkill. This means there isn't anything analagous to JBehave
> or cucumber - a plain text scenario runner with reusable steps - in .NET.
> I would love to see NBehave become a port of JBehave but taking advantage of
> C# semantics and language features. Right now there is a bunch of
> fragmentation in the .NET space. I haven't even heard of half these
> frameworks, which is a shame because I'd be happy to correspond with their
> authors. I have shared this vision with Morgan Persson and Joe Ocampo (the
> NBehave guys) and I am confident they are going in the right direction, but
> I haven't been in touch with any of the others.
> Whatever they are promoting it isn't anything I would call BDD. The point of
> BDD is to bring business stakeholders, analysts, testers and programmers
> together to describe application behaviour in a consistent and useful way.
> This splintering of frameworks, syntax-fu and not-invented-here syndrome is
> the antithesis of that.
> It would be great to see some cohesion across the various frameworks to
> create a robust BDD scenario runner for .NET. That would make me very happy.
> > nBehave looks good, but I can't find any documentation?
> > SpecUnit.NET is in the lead for me right now.
> > I just looked at specter, which looks interesting, but I'm not so
> > sure. I don't know how well that'd work in Visual Studio?
> > I just don't like the syntax of MSpec.
> > The thing with nBehave and SpecUnit.NET is that I hate all those
> > underscores. C# has the convention of using camel case, and I'd just
> > rather stick with that.
> > I'm almost to the point of just using nUnit and having a naming
> > convention for the tests.
