Need to get something off my chest

For the most part I have been out of pocket from the .Net community over the last 6 months due to new obligations I have taken on. These new obligations have given me the opportunity to explore other communities outside of .Net such as Java, Python and Ruby. All these groups have their quirks but the some things they do have is an expressive community that welcomes innovation and alternative view points.  Where as the .Net community I feel my view points and belief structure are contrary to the majority, so I don’t *feel* part of community so much as I *feel* a part of a small rebel faction (which is kind of thrilling in a StarWars kind of way).

As a community we strive to make better software for our fellow developer.  To make our lives simpler and more productive.  As a community we believe in open source software for the betterment of the community. Which brings me to my issue.

I may get flamed for this but maybe I just need to get my hand slapped to settle me down. 

As you may know Jimmy Bogard and I have a an open source BDD framework named NBehave. Jimmy, mainly has been working on this off and on and we have learned a great deal about BDD in that time frame.  We have experimented with various ideas that have been cultivated in the BDD community and are striving for best practices.  There are directions that we would like to take the framework  but we have not had time to move it in a certain direction just yet.  As an Open Source project we would love additional contributors to help us with the project and just get the community more involved, after all that is what open source is all about.

The key concept here is community. If you have an idea that is similar to a project that is in an alpha state, shouldn’t you simply contribute to the project to help grow the idea? As a fledgling community should we not galvanize on concepts to bring greater acceptance to the masses?  Or are we mainly focused on becoming the new Rock Star programmer?

Now the context of the issue. I came across a post today on BDD. Looks very similar to this post but instead of anonymous delegates it uses lambdas.  Cool idea and one that we are planning on implementing, oh wait we have that already. hmmmm??

One of my issues with open source development revolves around the very nature of this context. Why as a community do we insist on reinventing the wheel? Take for instance unit test frameworks in general.  There is NUnit, MbUnit, xUnit and I am sure I am missing others.  The point is they all pretty much do the same thing, just a little differently. Was there a fall out between developers on a certain concept? Where they started at the same time and grew up in separate camps? I don’t know.

There is nothing wrong with a little competition to spark innovation, I am all for that. But as a community should we at least communicate with one another to talk about concepts around frameworks that are so similar in nature? If you have conflicting view points on a particular direction then by all means create a new project but if the view points are the same then galvanize with the other projects to help strengthen the concepts and ideas around which the tool is being built, this will only strengthen the community.

I am not the type of person to be married to my code.  I believe in dating it.  It’s ok if you want to change it, enhance it or delete it.  I don’t really care.  What I do care about is the concept and principles upon which the tool is meant to serve.  I am not in this industry for the notoriety or the prestige.  I simply want to create good software with the help of the community.  I love conversing with other developers on ideas or concepts. This is what truly drives me.

I want to go on the record, that I do not think that the authors of StoryQ had ANY ill intentions or malice towards NBehave or other BDD frameworks. I am simply saying, why couldn’t the authors have contacted myself or Jimmy to help make NBehave better. The dialog would only have helped to strengthen view points and concepts.

BTW I have contacted Jimmy on any of this so if you have flame don’t send it his way.

About Joe Ocampo

My personal philosophy is simple: "Have a good strategy that sets the environment for success through the enablement of the whole. Be agile but with a mind towards pragmatism. Delegate to the best qualified individuals, but don’t be afraid to involve yourself in all parts of a job. Treat everyone with respect, humility, and with a genuine pursuit towards excellence." Respected business and technical leader with expertise in directing organization towards effective results driven outcomes. Proven ability to perform and communicate from both technical and business perspectives. Strong technical and business acumen developed through experience, education and training. Provides the ability to utilize technology, harness business intelligence and execute strategically by optimizing systems, tools and process. Passionate about building people, companies and software by containing cost, maximizing operational throughput and capitalize on revenue. Looks to leverage the strengths of individuals and grow the organization to their maximum potential by harnessing the power of their collective whole and deliver results. Co-Founder of
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

37 Responses to Need to get something off my chest

  1. redsolo says:

    I have been thinking of this for a while as well. Especially on the tools side there are soo many people who take a tool from one programming language and port it to another language just because it wasnt written in the preferred language. For instance, take the CruiseControl tool; people are porting it to .NET and ruby and for what reasons?

    Why not take the original tool and make it work with other languages? That will make the original tool much better and improve its feature set. CC isnt the only one: ant – NAnt – Rant.

  2. Well, that’s the one thing about open source is it not?
    For more explorations into open source issues check out the linux hater blog. Exchange “Framework” with “distribution” or “audio infrastructure” and it sounds damn similar. Sadly, that guy doesn’t give an answer why it is like that.

    It seems it is not in our species to be altruistic and collaborative. It is obvious that a theory of “survival of the fittest” would be developed by a human. Indeed, we see both in nature, i.e. fighting over limited resources as well as symbiosis throughout different species.

    This would be stuff for a lengthy debate but my first take is…most techies have a difficulty expressing themselves in language. They express themselves in code. If they have a different opinion on how BDD should look like, then they’ll express this opinion in code. As much as some people insist on the viewpoint in talk, many developers insist on their viewpoint in code. They become protective about it and don’t want to mingle with others.

    A different issue may be that for one framework to get extra attention, one needs a certain critical mass (look at evolution) – however, many developers don’t even have embraced TDD, why would they start BDD now? Indeed, I am using the standard testing frameworks, because I was sold to testing through Dan North and his takes on BDD. You can write BDD inspired tests by focusing on the ideas of BDD. Having expressive test names, considering desired behaviour and giving some consideration as to which test goes into which class helps me a lot to develop tests. it is obviously not the same, but hey…

    Finally, even techies need to sell their stuff. When I look at Nbehave’s website I get links to Dan North explaining BDD….but why exactly should NBehave be my choice and get code love?

  3. Khalid says:

    I agree with you that there are a lot of frameworks out there that do the same thing, almost the exact same thing. But when I think about it, the internet is very very very big. When I search for new frameworks or methodologies its almost a crap shoot as to what I’ll come to and explore. I am just happy to see people are exploring new things and advancing development technology, and usually in the end there is a core of decided community winners.

    On the topic of unit testing frameworks, you are right that there are almost too many, but the fact they are similar makes it easy to transition from one to the other. I jump from MbUnit to NUnit to MSTests all the time due to the differing requirements of a solution. Am I happy with it, no not really but I’m not mad about it.

    Oh and kudos on the BDD article your wrote. I wish I would have seen it before writing mine, probably could have written about something else, haha.

  4. Mark Hoffman says:

    I was discussing this very topic just yesterday. I probably sound overly harsh, but I believe that at least part of it stems from the rampant egos that are common in our industry. Everyone thinks that they know the right and proper way, and everyone else is pretty much just an idiot. So they cobble up their own solution to a problem that has already been solved, but not solved to their liking.

  5. James Avery says:

    The beauty of open source is that it is a true independent ecosystem. Lots of software is created, new software it created to explore an idea and challenge the assumptions of the old software, the old software improves or dies off. We should never try to stifle innovation because we want “one true testing framework”. I love the fact that xUnit.NET was created, it challenged so many of the testing standards… you couldn’t do that in an existing testing tool without breaking 100% of the existing tests out there which would be completely irresponsible. You often see new projects influence existing projects, a RowTest add-in was added to NUnit in response to MbUnit. Lambda mocking was added to Rhino.Mocks in response to Moq. A fluent interface was adding to StructureMap in response to Ninject.

    This is what a healthy community does!! An un-heathly community would stick with one tool and never challenge it.

    I spend a decent amount of time in the Ruby community and the same thing happens there. You see test/unit, spec/unit, rspec, shoulda… they each have different uses or bring a new idea to the table. I am sure there are more I don’t even know about.


  6. James,

    > Lambda mocking was added to Rhino.Mocks in response to Moq. A
    > fluent interface was adding to StructureMap in response to Ninject.

    I don’t think that this is historically accurate on these two.

  7. Joe Ocampo says:


    As far as taking projects from other languages, this is where I do see a need IF the target language cannot consume the framework or there is something that you would like in the framework that need to be tailored for the target language

  8. Joe Ocampo says:


    >but why exactly should NBehave be my choice and get code love

    This is what I was worried about people taking from the post. I am not saying I want you to love any one framework. What I am saying is if the ideas are INDENTICAL why not converge the thought stream, rather then recreate the wheel.

  9. James Avery says:

    I am pretty sure both of the new tools showed up before those features were added to the existing tools. We can argue whether it was done as a direct response or not, but I believe the timeline is easily verifiable.


  10. Joe Ocampo says:


    >This is what a healthy community does!! An un-heathly community would stick with one tool and never challenge it.

    I agree completely agree with you. What I was trying to say is when two projects are created around the exact same ideology, why not converge on the THOUGHT stream. This will only help strengthen the ideas an concepts on which the ideology is based.

  11. Nate Kohari says:

    Whether or not a given project had feature X first, competition is a very healthy aspect of the OSS ecosystem, and is good for everyone. I would also argue that when it comes to dependency injection, unit testing, and mocking, there are clear differences in features and API between the different offerings.

    I originally created Ninject to cure some of the pain I was feeling with Windsor, but I’m very pleased that others have found it useful as well. I’ve often said that if someone doesn’t like Ninject, there are plenty of other great alternatives (Windsor, StructureMap, Autofac, etc.) available to choose from. People should be pragmatic and choose the one that best suits their needs.

    Isn’t choice a *good* thing?

  12. James Avery says:


    >What I was trying to say is when two projects are created around the exact same ideology, why not converge on the THOUGHT stream.

    I can agree that communication would be good, and that could lead to collaboration or going in separate directions. My point was just that I think diversity is good in most cases because the separate projects usually offer a different approach or way of doing things.

    I think part of the allure of open source is re-inventing the wheel though, I think Phil pointed out in his post recently that sometimes the best way to immerse yourself in a technology is to contribute. I could go and write a test framework and I am sure that it would help me better understand unit testing, and since its open source its not like I am costing my company money or hurting anyone. It’s my time and my dime. :)

  13. Jon Kruger says:

    I notice the kind of thing when Microsoft tries to come up with their version of some open source tool that we’ve all been using. Why does MS have to write it all from scratch? Sure, if they can do it better, more power to them (I haven’t seen this happen yet), but if you’re Microsoft, what is better than lots of smart, passionate people doing FREE work that will enhance your platform (.NET)? Why not embrace that and contribute to it to make it better?

  14. Nate,

    > Isn’t choice a *good* thing?

    It’s a good thing when the choices are good, or when the person doing the choosing has the insight to know which choice is a good choice.

  15. James,

    > I believe the timeline is easily verifiable.

    I guess that’s kinda my point… the timeline isn’t really the best indicator of the motivating factors.

  16. James Avery says:

    My point is that I believe diversity in open source drives innovation and new projects often influence existing projects to adapt and improve. Do you disagree with that?

    Specific time lines and motivations are inconsequential to that point.


  17. Jeremy Gray says:

    I would, for lack of a better term, like to call bullshit. And probably get more than a bit ranty in the process. Bear with me. ;)

    Let me take a moment to describe to you my experience during the last week or so. Not a full-time week or so, of course, just during the last week or so.

    Some number of sprints ago it became clear that I needed to push my client’s test automation in a more specification-driven direction. Enter BDD and its incarnations in various tools. Finally, during our current sprint, I was able to budget the time to do this. Now, to be clear, I’ve been following the BDD space for some time now in prep for this move. I also went back and refreshed myself on the current state of the concepts, techniques, and tooling before making any final decisions as to what to do. Here’s what I found, and hopefully this will be enlightening to some people working on these tools, specially NBehave. (Some of these may not be technically correct, but are simply what is apparent based on what is written about these tools out in the community, which is tantamount to being technically correct at the end of the day for someone who is trying to research the numerous options with limited available time.)

    .net BDD tooling, in its current state, in the form of formalized frameworks or opinionated test base classes, etc., can hardly agree on terminology let alone approach. Is it a context? Is it a scenario? Is it a specification? Because? When?

    The vast majority of .net BDD tooling, as currently implemented, also without question attempts to replace perfectly good test automation tooling. Why are you guys constantly trying to replace NUnit, MbUnit, etc., instead of leveraging them? To argue that other BDD tooling isn’t working together with you is a bit like the pot calling the kettle black in light of this.

    The remaining .net BDD tooling that doesn’t attempt to entirely replace existing test automation frameworks is directly tied to one of them, without an abstraction in place to allow people to integrate with the tooling of their choice.

    .net BDD tooling’s lack of integration with other existing tooling, most especially test automation tooling, all but eliminates all sorts of leverage provided by said tooling (and other tooling that is built upon said tooling.) Why should adopting a BDD tool force me back to the command line, for example, losing all of my IDE-integrated (or otherwise) test runner goodness, for example? Why am I having to mess with my build scripts to even get my tests to run again? (and yes, I am fine with messing with the build script to get BDD reports generated, but come on!)

    And, here’s the kicker: In far less time than it took to even get caught up on the current messed-up state of .net BDD tooling, I was able to write my own from scratch. It settles on the only terminology that seems even remotely agreed-upon by the community at large (Given, When, Then). It is currently opinionated in that it is nicely integrated with MbUnit Gallio but has been structured so that dependency can easily be isolated (and was in fact originally written without any special Gallio ties. It now kicks off RunStep calls, marks individual parts of the context Pending, Skipped, etc. for better reporting, but that is about it.) It provides a clean syntax for establishing context and the event, but without trying to take over as the test framework and runner. In other words, you still write [Test] methods (aliased to [Then] if you so please) to do individual assertions and therefore can still use all of your favorite tooling goodness (e.g. test runners, build process integration, reporting, etc.)

    Am I going to release this thing? Almost surely not, as it was written for a sensitive client. However, the fact that I could write it faster than sort out the mess the available tools are in boils down to something I almost don’t want to say but I guess I really have to:

    There’s not much to building BDD tooling. I’m sorry, but having just finished writing one, there’s just not that much there. As such, it is very easy for people to crank out opinionated tooling that integrates with their specific project better than any one of the existing pieces of available tooling could. And that’s without even accounting for the time spent trying to sort out the current mess of tooling beforehand. If you are seeing too many (at least what you think are too many) tools pop up independently without hearing from their authors, now you know why.

    If as a BDD tooling author you want the above facts to change, there are things you need to do. First off, start releasing. (The most recent NBehave release is _how_ old now? Heck, the most recent post on any work being done on it goes back months from what I recall off-hand while writing this) Second, get terminology agreed on. Third, integrate with existing tooling and stop trying to replace it. Fourth, make sure those integrations are easily pluggable.

    PS – if this post shows up as one giant run-on paragraph, blame the blog not me. There isn’t a single thing on this page that suggests what markup is allowed or not allowed, whether or not my text is being treated as plaintext, etc.

  18. Joe Ocampo says:


    >Isn’t choice a *good* thing?

    Choice, as Scott pointed out choice, is good when the person doing the choosing is informed and understand the context on which the problem context to which the solution has been provided matches best.

    I don’t have a problem with other BDD frameworks in .Net. Several exist already a new ones are being created. The issue I have is that before you go and create a new one *TALK* to the contributors of the other frameworks to insure you understand directional influence and ideological constructs. If you idea does not fit then of course why would you create a new project. BUT if it matches or enhances the thought, then contribute to the project. In only helps everyone in the end.

  19. Joe Ocampo says:


    I agree with your points.

    Microsoft perspective is probably based on market capitalization and intellectual property more then anything else. Is this ethical, well in my opinion no. But does it make share holders happy, probably.

  20. Jeremy Gray says:

    Whee! It showed up with formatting! :D

  21. Jeremy Gray says:

    @Joe – some people are operating under greater pressures than you seem to think. I didn’t have time to go and talk to every tool creator to figure out why they did things the way they did and what I could do to change it for my environment. At the end of the day I needed to deliver, and after surveying what was available and finding both that none was appropriate and that it was far faster to create one than to talk and modify, I knuckled down and created one. I can easily imagine that this is how many of the existing tools came to be and later came to be made available publicly. Heck, some of the existing tool’s authors have made that quite explicit in their documentation, posts, etc.

  22. Joe Ocampo says:

    @Jeremy Gray

    That is what I was looking for! :-)

    I wanted to know all your opinions regarding why you chose to make a new one vs. contribute to an existing project. That “thought stream” never took place between anyone. Could it have helped NBehave? Could it have helped you and I better understand BDD? Could we have come together and elicited greater concepts? Could you have learned the difficulty oh why certain directions where taken? The fact is we will never know the answer to these questions because the dialog never occurred.

    The reality is that what you did in short period of time is great but you NOW made known issues that Jimmy and I were not even aware of.

    One of the reason personally why we haven’t focus on the Story Runner is that frankly it creates a lot of unnecessary friction. I didn’t realize at the time I created it (although others pointed it out) but the jury is still out on the applicability of Story Runners, so who knows.

    Again the focus was not to discount your efforts but draw attention to the fact that as a community we don’t communicate with one another to help learn from each other.

  23. Colin Jack says:

    “One of the reason personally why we haven’t focus on the Story Runner is that frankly it creates a lot of unnecessary friction. I didn’t realize at the time I created it (although others pointed it out) but the jury is still out on the applicability of Story Runners, so who knows.”

    Definitely interesting especially as it doesn’t match my own experience.

    Writing acceptance tests is definitely hard but whether I use a story runner or not has little effect on that complexity, neither does switching to context/spec. The difficult more comes from making sure the data is there for the AT, working out out to write complex multi-step AT and that sort of thing.

    Having said all that I’ve seen enough to think its worthwhile and I definitely saw some the benefits Dan North was going for.

    Oh and I should also say that experience has taught me one thing about good acceptance tests, code wise they need a lot of reuse so composition is key. Thats one of the many reasons I think xBehave has some legs, though I also use context/spec a lot (basically for everything other than acceptance tests).

  24. Jeremy Gray says:

    @Joe – no offense, but I think you are still missing the larger point. As much as I might like them to, my client doesn’t pay me to talk to you and wait for new versions of NBehave. They pay me to deliver.

    Put yourself in my shoes for a moment. You want to go BDD. You look around. The existing tools are in general very stale. Progress is unclear. They can’t even agree on terminology. They try to take over for good tooling you already have in place. And drop features while doing it. By forcing a tooling change, they eliminate the ability to use yet _other_ supporting tooling you already have in place. Rolling your own will take less than a day, and that’s including time to demo a few alternate syntaxes to your team. Maybe you’ll need to take another half-day to layer on more reporting later, but you don’t need that degree of output right this minute. Your client is looking at their watch. What would you do?

    This going to sound snide, but: reading the above paragraph, you should consider yourself lucky to be getting any feedback at all. I’ve already had to drop more than an hour of billable time today just to give you what I’ve given you so far. Again, just trying to get you to put yourself in my shoes for a moment.

    As for the “thought stream” as you put it: We’re in it now, but I’m honestly not sure you can really expect a dialog to have been opened any earlier. I coded yesterday, you posted last night, I responded this morning. I wonder how many others already have rolled their own BDD for the same reasons I did but aren’t surfacing in the comments. Had you not posted with such good timing, I wouldn’t have surfaced either. Why? Because the existing BDD tool projects need to get their fundamental issues sorted and I need to move on. You got lucky on this one and I came out of the woodwork to give feedback.

    You will keep seeing new tools pop up as long as the existing tool authors fail to resolve the existing problems. The onus is on you, not on would-be end users who need to deliver and therefore roll their own instead of (as it seems you might suggest) trying to spearhead some kind of .net BDD tool unification revolution. They have neither the time or reason. In the meantime, you shouldn’t blame them. Especially not the ones who rolled their own and shared it so that others might benefit.

    Go talk to Scott, Jeremy, et al. Get things sorted amongst yourselves. Put up one consistent front. Or at least put up a small number of opinionated fronts but where the pros and cons and situations for each are clearly spelled out. Either way, get your terminology in check. Then cut some releases, as neither you or Scott have released in ages. Then and only then _might_ you be able to justify getting upset when things like StoryQ pop up without you hearing about it first.

  25. Joe Ocampo says:

    > my client doesn’t pay me to talk to you and wait for new versions of NBehave.

    I am not suggesting that you drop what you are doing when you have a thought about improving an idea or concept on an existing framework. I completely understand your perspective and why you did what you did. All I am saying is that we haven’t received any feedback concerning NBehave other than, general question regarding usage scenarios.  

    > trying to spearhead some kind of .net BDD tool unification revolution.

    My goal is not tool unification so much as it is about collaborative thought. Like you mentioned I have gotten what I wanted out of this post and that is the feedback and motivation for similar thought models. While you mention that my timing correlates to your post. I was addressing your post so much as I was addressing the code of of StoryQ who’s initial checkin was Jul 23 so the thought model had a month to churn. Again my focus is on communication not the code.

    But having read the comments from others in this post and your comments, maybe in open source software, when a developer create a similar project to your own that is their form of communication. It is more of pull model then a push model. It is up to the other the other frameworks to pull the intentions of creation the expect to be involved in the thought stream.  This is just counter to how I work on a day to day basis.

    > … Either way, get your terminology in check

    hmmm I will have to take that as constructive feedback. I don’t want to read into it.

  26. Joe Ocampo says:

    @ Jeremy Gray

    BTW How are you involved in all this, I don’t see your name associated with StoryQ or the post I referenced? Just asking for sanity sake.

  27. Jeremy Gray says:

    @Joe – Your initial post’s slightly ranty tone got me into a slightly more ranty mode which seems to have escalated bit by bit with each of my replies, so don’t read too much into that particular phrase. ;) The short alternate take is that it doesn’t help .net BDD when, for example, I see Concern, Context, Scenario, Spec(ification), etc. all showing up at roughly the same spot in the various frameworks’ usage examples.

    My particular backstory, complaints, etc. aside for the moment, I do think that in general we would be in violent agreement on the point around the silence of those working on and releasing alternate projects. It obviously would be helpful if they piped up and worked with the other projects to figure out where a new project could best fit into the space and what everyone in the space could do better.

    In case this hasn’t been thought of so far, both (potential) end users and new project owners could probably benefit from having a bit of a central rallying point for BDD in .net. If new users had a one-stop shop they could go to to learn about BDD, how to apply it in .net, what the available tools are and how they compare, what their styles are, where each one shines, etc., and if tool owners could go there to openly and transparently collaborate to align each tool to better support their particular applicable cross-section of the user space, I could imagine that being a win for everyone. Perhaps something as simple as a wiki, but preferably something stand-alone, identifiable, and polished, that could be given link-love from every which way so as to get it ranked nice and high. Add in a syndicated feed covering the various authors and contributors for the various tools, maybe some forums for people to talk BDD as it both relates and does not relate to specific tools, etc. and I think you’d come out with something really quite beneficial for the community.

    Not that I have the time or inclination to start it up, of course. ;) My personal suggestion would be for the project owners to gang up and do it for the benefit of all.

  28. Joe Ocampo says:

    @Jeremy Gray

    Understood I have been known to become very passionate from time to time.

    You thoughts are completely inline with my vision on what would be great for the .Net community.

    About the only thing I would like to add is that there is a mailing list I created a while back for BDD:

    pass it on. There has not been that much activity around it though.

  29. Jeremy Gray says:

    @Joe – I’ve been popping by that group from time to time to see what is going on, and will be sure to both continue doing so as well as to pass the link on to my team members and associates who are interested in the subject.

  30. Scott says:

    “Choice, as Scott pointed out choice, is good when the person doing the choosing is informed ”

    See, here’s the thing about being uninformed. You don’t *know* you are uninformed until someone points new information out to you. At which point, you become informed and, once again, don’t know that you are uninformed.

    So there are three or four unit testing Fx for .NET. Why should I not write a fourth? Maybe I have an idea for doing things differently (a’la xUnit) that will make the process of writing unit tests easier/smarter/better.

    I mean, should we have stopped with Xerox PARC? Why did Microsoft come out with .NET when Sun had already written Java? Do we need another GC framework that runs on Windows?

    Shouldn’t we all be driving Model T’s 2008 edition? You have your choice of colors provided you choice black.

  31. Scott says:


    You mean we don’t have 12 grammar checkers for this little comment box already? ;)

  32. Jeff Brown says:

    I think you may be undervaluing the implementation concerns vs. the conceptual ones.

    The xUnit community has largely reached a consensus as regards to tests consisting of fixtures containing multiple test cases with with one or more assertions of which there is a moderate assortment involving validation of state and behavior.

    So why have MbUnit, NUnit, xUnit.Net, CSUnit, MSTest, and more all within the .Net space?

    Well, because each framework differs in how the general concepts have been applied. There is significant engineering effort involved here to optimize across a wide range of details.

    MbUnit v3, for example, emphasizes rich reporting, extension by subclassing, broad applicability to unit testing and integration testing scenarios, and powerful integrated tooling.

    Other projects emphasize other objectives. xUnit.Net is a fascinating study in minimalism, test semantics and language-oriented programming.

    It’s FASCINATING to watch these ideas and systems develop!

    Ironically, I just finished writing a reply to a query about providing enhanced database integration testing support in MbUnit.

    I explicitly questioned whether this was something that really needed to be reinvented. Moreover, I cited an existing implementation of these ideas for inspiration (NDbUnit).

    Before anything happens wrt. database integration testing in MbUnit, we’ll be sure to make a proper study of what’s out there, to decide our approach. I fully expect in this case that we will adopt someone else’s work, contribute enhancements, and build more cool stuff around it.

    Unfortunately other time it turns out that the existing tools don’t meet out desires, but it’s always worth looking anyway because it can help us to better understand our true needs!

    I am quite happy endorsing and supporting the excellent work of others.

    I am also quite happy to borrow and learn from others when I perceive a significant opportunity for improvement in the form of a new implementation.

    Anyways, that’s it. There’s no malice or neglect involved in choosing to rebuild a tool fashioned after those others have built before; there is only quiet respect and genuine admiration.

  33. Harjit S. Batra says:

    I agree wholeheartedly with a lot of what Jeremy Gray has to say:
    - Lack of consistency in terminology is very off-putting
    - Lack of development progress creates doubt about the future viability of any tooling, NBehave or otherwise
    - The presence of too much choice, especially in nascent tooling, is actually worse than little choice – since it also creates doubt about “backing the right horse”
    - Failing to leverage and/or tie in to existing technology/tooling makes it a harder sell to management, who are leery of OSS any way, but are also unwilling to open their purse strings for COTS software
    - The lack of documentation, with nothing more than a trivial example, hurts terribly – since it hurts the understanding of the tooling, and its applicability to more complex scenarios

    Finally, as someone else pointed out, getting to unit testing was a recent experience for them, and understanding and selling the benefits of that might in itself be an uphill task. Add to that that none of the BDD tooling sites that I have visited so far have been clear on why BDD is good for the developer, business analyst, or organization shows up as a disconnect between the development of the tooling and the ability to sell the benefits of using the tooling.

    My opinions above are more reflective of a user of BDD tooling rather than as a developer of BDD tools, which is what the original post was all about, but I hope it will help when the idea of different developers coming together materializes.

  34. JH says:

    I have at least 6 #2 Phillips screwdrivers that I have either accumulated or purchased over the years. Sometimes I search for longer than I should to find the one with the nice rubber handle. Other times I grab whatever is first to satisfy my search.

  35. Joe,

    The unit test frameworks are an interesting example, as you quite rightly point out there are many of them and they all seem to do the same thing. As Jeff points out each framework has different objectives but sure frameworks copy each other, once upon a time MbUnit was the only framework to have RowTest and Factory attributes – not any more. Soon even the concept of Pairwise will be copied. Do we mind, no, these concepts are open to be copied as much as the software we open up is. If folks find them useful and want them, who are we to stop them. MbUnit will be adding it’s own constraint model, it is a cool idea (and kudos to NUnits charlie poole for creating the concept) and folks will find it powerful and useful. That is the key to all that we do in this space, the framework serves its users.

    The nature of OSS is rarely about sharing and almost always just do it (and wait for it to be copied). As someone points out here, if they have a need then either give them a way of letting them do it or supply them it. Better yet, if folks are working around problems with your framework, understand why and see if they can’t supply you with a patch or failing that the problem and how they solved it. OSS is peaks and troughs when it comes to activity and time and you can’t promise it will be done tommrow but at least it has exposure.


  36. Rob FE says:


    Developer and co-designer of StoryQ here

    Sorry it took me so long to find your post! I feel so slack. I think I’m going to go and set up a google alert right now…

    I’ve been getting back on a a bit of a StoryQ bent now – having needed to build before I could really do what I wanted with the new version of StoryQ (which is now released, and pretty well documented at

    The simple answer is that back when I built storyQ, NBehave didn’t integrate into the resharper test runner or teamcity well enough for us. We only had developers *writing* the tests, so it made sense to use an *internal* dsl… The first usable version only took two days to build (although I’ve put in a LOT more work since then, as I’m sure you have). Gallio didn’t exist either.

    That’s the only reason we built our own system rather than helping you guys out with yours.

    Fast forward to today, and I’d say that StoryQ and NBehave are both excellent .NET BDD Frameworks, each addressing a slightly different problem space / workflow. I wouldn’t hesitate to recommend, use or contribute to NBehave if it seemed to fit the project better than StoryQ.

    I have to apologise – back then, I wasn’t so good at community engagement and wasn’t a part of the BDD list on google groups. I hope you saw my post there regarding the new release!

    Regards – Rob Fonseca-Ensor (@robfe)

  37. Anonymous says:

    Using a BDD framework, scenario specifications can be automated as acceptance tests, thereby creating active affidavit that is in accompany with the code. These days there is a plethora of Open Source BDD frameworks covering just about every programming language and platform.

    toshiba direct coupon code