Build mechanism for code generation of test stubs from textual requirements

[MehdiK]

Ported from BB. Created originally by nootn:

It would be cool if you could take textual requirements in a specified structure and generate BDDify code stubs from it (possibly choosing whether you want the Fluent API or not).

This would solve a lot of issues around a developer being a bottleneck for creating the "documentation" (as the developer has to code it up). If a customer could write the requirements, then a developer could just generate the code from it that would be a big time saver.

One idea I had was if you had implemented the Markdown output (https://bitbucket.org/MehdiK/bddify/issue/9/markdown-output-as-well-as-html) then you could almost use the convention for how you render that and reverse engineer it to generate code.

Another option would be to generate some web app that does it in a structured manner but that involves hosting issues. A client app would also work but introduces deployment/installation issues.

[MehdiK]

I don't think this is such a valuable feature tbh. Closing this for now and we can always reopen and discuss it later.

[paulvanbladel]

Hi Mehdi,

Not sure it is that invaluable. In many enterprises there are really distinct roles involved in BDD ranging from business analysts, functional analysts, (lead) developers, ... The functional analyst would in fact be the key role initiating and driving the BDD 'machinery'. Often these guys and girls don't have experience with visual studio or even there might be ceremonial reasons why they don't want to use it :) What they can be learnt though, is writing a simple user story in markdown style, which could be 'imported' as BDD story/scenario and that's what this issue is about, no? thanks for reconsidering. cheers paul.

[robdmoore]

There is already a tool out there to do this - it's called SpecFlow and correlating between code and text is not easy (but obviously, feel free to use it if it helps solve a problem for you - I know people that use it successfully).

For me this comes down to the fact that automated testing is something that should be done in conjunction with developers - not in spite of them. If you have testers that can't write code then use them for their strengths - their unique testing mindset. Get them to pair with a developer to get the code written and then give the developer the most efficient tool to write those tests (to my mind this is one of the strengths of Bddfy - it's so easy for developers to use).

[mwhelan]

Totally agree that two-way syncronisation of specs and code is hard, and not worth chasing. I think a one-way conversion from specs into code is useful though, and I've knocked up little winforms apps in the past to do it.

I've found that the three amigos will tend to produce Given When Then scenarios in a text or Word file before a sprint starts, and it's nice to have those converted into "not implemented" BDDfy scenarios before the work in the sprint starts, then the sprint work makes the scenarios go green. I used this as the basis for my approach: http://jonkruger.com/blog/2010/05/10/specs2tests-turn-those-acceptance-criteria-into-bdd-tests/

[mwhelan]

StoryQ used to have a nice WPF app for doing the same thing - creating scenarios at different levels of detail with attributes for different testing frameworks.

[paulvanbladel]

@mwhelan @robdmoore Thanks for the prompt feedback. I'll check more in the depth the sources your provided.