--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
Thanks for the thoughtful response, Dan.
I think you were actually close to answering what my real question was (even though it was poorly presented in my post). The example above was contrived.What artifacts do folks normally use to capture the "scenario-extraneous" details that come out of discussions/meetings/etc, like the ones you describe in your response? If I'm developing a "living document" shared by me and my stakeholders, I'm assuming capturing those details would be useful, and that I would want to have them "at hand" for anyone who shows up late to the game. The answer of "you have to make something up" is acceptable.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.
Visit this group athttp://groups.google.com/group/behaviordrivendevelopment.
Hi Tom,
I like your builders. Care to share a bit more of what they look like?
Thanks
cliff
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.
What it mostly comes down to is that I try to describe "what" I'm doing in my tests, not "how" I'm doing it, which is exactly the reason why I use these builders that setup the test context and properly named variables.
I try to express my specs in the same way the business talks about them; they can use examples but in most cases they don't and just use the domain language...
For me personally Liz's example is not high-level enough, it so focuses on the how and not the what... But I do believe she states that in her post as well. (Typing on a cellphone ATM, so I can't check it.)
Regarding the gherkin language: I don't see a reason to add yet another "programming language" to write your specs, as you typically don't have the same tooling available for it. If you write a simple parser for the example I gave, replacing non-letters with spaces, you get a similar outcome without sacrificing any usability, flexibility and tooling...
For me personally the business should be able to read the specs, I experimented a lot with having clientsite specs using gherkin, but it was to much of a hassle for both me and my clients. YMMV
Thanks Liz. Very interesting code you have.
I couldn't find any examples in my boss work' however this is a similar approach but it doesn't use builders:https://github.com/ToJans/mauritius/blob/master/Example.Specs/ProjectSpecs.cs
I hope it provides you some value...
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.