I am a bit of a vocal proponent of the Behaviour Driven Development methodology (aka BDD). I've been applying BDD for a couple of years now, and have adopted StoryQ as my framework of choice when developing DotNet applications. Even though I have been unit testing for many years, and had previously shifted to a test-first approach, I've found that I get much more value out of using a BDD framework, because my tests capture the intent of the requirements in relatively clear English within my code, and because my tests can execute multiple assertions without ending the test halfway through - meaning I can see which specific assertions pass/fail at a glance without debugging to prove it.

This has really been the tip of the iceberg for me, as I've also noticed that I am able to debug both test and implementation code in a more targeted manner, with the result that my productivity has grown significantly, and that I can more easily determine where a failure occurs if a problem happens to make it all the way to the integration build due to the output that makes its way into the build logs. Further, the StoryQ api has a lovely fluent syntax that is easy to learn and which can be applied in an extraordinary number of ways, requiring no external dependencies in order to use it.

So with all of these benefits, you would think it an easy to introduce the concept to the rest of the team. Unfortunately, the other team members are reluctant to even look at StoryQ to evaluate it properly (let alone entertain the idea of applying BDD), and have convinced each other to try and remove a number of StoryQ elements from our own core testing framework, even though they originally supported the use of StoryQ, and even though the code they wish to remove doesn't impact on any other part of our testing system. Doing so would end up increasing my workload significantly overall and really goes against the grain, as I am convinced through practical experience that it is a better way to work in a test-first manner in our particular working environment, and can only lead to greater improvements in the quality of our software, given I've found it easier to stick with test first using BDD. To further clarify, the majority of the unit tests we have tend to be quite brittle and difficult to maintain, a holdover from years of poorly applied testing where a reluctance to stick with a test-driven process has seen developers fall back on old habits and do all of their testing at the end of the project (these same people claim to be Agile!).

So the question really comes down to the following:

  1. What arguments can I use to really drive the point home that it would be better for this team to use StoryQ, or at the very least to adopt the BDD methodology?
  2. Can you point me to any anecdotal evidence that I can use to support my argument to adopt BDD as our standard method of choice?
  3. What counter arguments can you think of that could suggest that my wish to encourage the team to adopt BDD might be in error? Yes, I'm happy to be proven wrong provided the argument is a sound one.

NOTE: I am not advocating that we rewrite our tests in their entirety, but rather to simply start working in a different manner for all future testing work, and preferably in the manner in which we engage our customers.

And for those of you wishing to learn more about BDD, the following links may be useful:

For those interested in more details, we're a small team of 4 working on about 5 large projects. The "pilot trial" for BDD ran for about 2 months initially, with another approximately 4 month period following. Team accepted that I should continue to work this way and were to do their own trials. I've been BDD-ing for about 2 years now since the trial ended, while the others have become very good at ducking the issue. Rather than forcing a "confrontation" over the issue, I'm looking for ways to gently persuade the team to get off their collective behinds and make the time to do their bit.

  • 3
    Let's think about "THEM" - why do they want it removed? Must be beneficial for them - have you tried finding out their benefits FIRST and seeing what middle ground can be reached BEFORE proposing your benefits :)
    – PhD
    Commented Mar 26, 2012 at 1:51
  • 2
    Try less selling and more educating. In my experience people don't want to be sold something but are always willing to learn something new. Then let the cards fall where they may. If they still are against it you failed as an educator or bdd isn't all that you say.
    – Kevin
    Commented Mar 26, 2012 at 3:09
  • 1
    @Kevin I think you missed my prior comment to Nupal, and perhaps the point of my question entirely. You've taken a single word from my question and interpreted it way out of context. I am actually trying to educate, and not to simply "sell" as such. I'm looking for specific points that I can use to help me to overcome an unnecessary reluctance to look into doing something different. Please do answer if you are knowledgeable about the subject matter, rather than merely providing provocative statements about my abilities or the technology, which are decidedly unhelpful on your part.
    – S.Robins
    Commented Mar 26, 2012 at 6:28
  • 2
    Binary decision diagrams? Buy a copy of Knuth's TAoCP vol 4 and lend it to them. Commented Mar 26, 2012 at 8:53
  • 2
    I think the problem your team has is not with BDD itself, but rather an issue of development methodology fatigue. I'm suffering from this myself. Too many methodologies come along that promise to revolutionize development. Unfortunately a few months later there is always another new methodology and toolset. I've come to view it as an annoying distraction rather than an opportunity to improve. To introduce BDD you are going to have to overcome this problem. Commented Mar 27, 2012 at 10:23

3 Answers 3


What arguments can I use to really drive the point home that it would be better to use StoryQ, or at the very least apply the BDD methodology?

"The customer wants it."

IMO you want to sell BDD to your customers/domain experts at least as much as to the development team.

BDD is a collaborative outside-in process where multiple stakeholders are involved. Benefits of BDD are not just for developers to automatically infer their test code from acceptance tests, they also lie in the creative cooperation that takes place between technical and business people to produce valuable, well-defined specifications of the system's intended behavior.

Giving customers/business analysts access to an interface where they can run each executable specification, control their status and see the progression in their implementation is generally much appreciated as well.

There's a presentation by Dan North on how you can sell BDD to the business : http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

  • I've seen that presentation and you're right, it's a good way to approach introducing the concept to the customer. In my case, I need to take a few baby steps. If the only thing I can convince the team to do is to adopt the language, I may have a chance to encourage the full method to be applied. I also need to deal with the issue that most of our customers are internal, and less business focused. Your point however is well noted. :-)
    – S.Robins
    Commented Mar 26, 2012 at 22:36
  1. In a team reluctant to adopt BDD, there likely are no "arguments" that you can use to "convert" your colleagues into full-scale adoption.
    I think the best you can do is to convince them to give it a try ("smoke test", "dry run", "pilot project") - especially if you make it perfectly clear that you'll drop the idea if testing results are negative.
  2. Your approach for finding anecdotal evidence fits perfectly to the idea of convincing team to give it a try. For that, I'd simply search the web for something like "Behavior Driven Development success story" and pick what feels easier to use to me.
  3. There are couple counter arguments I can think of that could suggest that your wish to convert the team efforts to BDD might be in error.
    None of these are particularly constructive, especially from the point of view of a "change advocate" but unfortunately you'll likely have to deal with exactly this kind rhetoric (BTDTGTTS):
    • you can't guarantee that overall team productivity will improve
    • you can't guarantee that efforts invested into adopting BDD will give substantial ROI
    • team was doing sufficiently well without BDD, risk of changing current approach is not justified
    • Google (or Microsoft, or IBM - just fill in the name of whatever "respectable" software vendor) are going just fine without BDD, which "proves" that BDD is not necessary
    • non-BDD approaches weren't given a fair chance in comparative testing
    • BDD might be generally OK but for this and that module / project it is not applicable

Per my experience, least painful way to address counter arguments like listed above was by performing a limited controlled test run for a proposed change.

"Limited testing" status essentially invalidates three of four arguments above, except for one about "respectable vendor", which could be countered by providing anecdotal evidence of success story (anecdotal evidence won't probably work for a "big bang change" but for limited testing it is good enough).

If the change is indeed worthwhile and test run is arranged properly, you will notice a positive shift in team and management attitude, making transition to full-scale change smooth and painless.

Another benefit of limited test run is that it lets you clarify and adjust target process detail without causing too much trouble and with lower risk of "reputation damage" to the idea. Every time I participated in such test runs, I was pleasantly surprised to find out how smooth it was to switch to full-scale adoption having most important details set and clarified in test run.

  • Thanks for the thoughtful answer. As it happens, I have been successfully engaged in a limited test, followed by an acceptance by the team to allow BDD to be applied indefinitely. The productivity improvements have been measurable, but as you mentioned there is no guarantee this would necessarily apply to the whole team without finding some way to encourage each team member to try it out for themselves, which is incidentally the motivation for introducing the question.
    – S.Robins
    Commented Mar 26, 2012 at 22:33
  • @S.Robins interesting. That limited testing you mention, for how long did it run? what part of the team was involved?
    – gnat
    Commented Mar 27, 2012 at 5:57
  • We're a small team of 4 working on about 5 large projects. The "test" ran for about 2 months initially, with another approximately 4 month period following. Team accepted that I should continue to work this way and were to do their own trials. I've been BDD-ing for about 2 years now since the trial ended, while the others have become very good at ducking the issue. Rather than forcing a "confrontation" over the issue, I'd rather find ways to gently persuade the team to get off their collective behinds and make the time to do their bit! ;-)
    – S.Robins
    Commented Mar 27, 2012 at 6:59
  • I see. That makes your question even more interesting. I need some time to chew it up; as of now I simply can not imagine how it would be possible to make further progress (save for "unfair" approaches like utilizing power of micro-management)
    – gnat
    Commented Mar 27, 2012 at 7:35
  • @S.Robins while I have our attention - do you have modules that "mix" BDD and non-BDD parts or there is sort of separation to 100% BDD / 0% BDD modules?
    – gnat
    Commented Mar 27, 2012 at 8:34

It may be time to recruit management. If you have given a try and seen solid results, but the team is balking, management may have to get involved.

This is especially true if they are hurting the companies most productive team member. Be prepared for backlash. You may start by approaching management and seeking to have the team stop undercutting you by taking out your test cases.

  • 1
    I don't know if I agree with this. Are you saying that with no developer buy in the right approach is to get management to force it down developer's throats? Does that not lead to resentment? Independent of the merits of BDD, I think that will lead to worse results. I.e. you'll have won the battle and lost the war.
    – Kevin
    Commented Mar 27, 2012 at 14:33
  • @Kevin I agree with Kevin on this one. Resentment and ill feeling can fracture a team very quickly, and that in itself can be a greater risk to the team's productivity than simply leaving them to work inefficiently. Kevin's comment reminds me of that proverb about not having a nail. In this case, I'm not seeking to do something drastic or heroic simply to have my way. What I'm looking for is my "nail".
    – S.Robins
    Commented Mar 28, 2012 at 2:14
  • The team is already against them as evidenced by the fact they are taking out test code they wrote. That is pretty hostile in my mind and warrants intervention of the development manager. That is their job, to make the whole team run smoother. Commented Mar 29, 2012 at 16:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.