Can xUnit frameworks and BDD work together?

Some of the resources I read.. refer to BDD as a response to 'Bad TDD'.

• Spe开发者_StackOverflow中文版cification of behavior vs Verification. No inappropriate intimacy between tests and implementation
• Use of ubiquitous/shared language between business-development-testers
• Terminology emphasizes 'behavior' over 'testing'. So Given-When-Then, Context, Scenario, Examples vs Test Suites, Fixtures and Cases.
• Live specifications

Not sure if I've missed more benefits.. please pitch in.

Given that most users (maybe a local phenomenon) 'collaborate' in the creation/elaboration/clarification of the specifications but are not interested in editing/viewing/executing/maintaining the automated versions (of course they expect all the specs to be met by the software):

is there any aspect of xUnit (say NUnit for instance) that prevents it from being a good tool for BDD ?

• Writing in terms of Specifications is a skill that is tool-agnostic.
• Ditto for ubiquitous language. It just needs effort to get it out
• Note the above mentioned constraint. Assume I adopt a xUnit test naming style that is aligned with the BDD Given-When-Then style.
• I get/create a tool that uses the above naming convention to generate similar "live docs" from the test result files.

Can someone mark the "Here be dragons" on my customized BDD map...

Here are the dragons for you, then.

1. Automation of GUIs remains hard, no matter what language you do it in.
2. It's harder to phrase a code-based DSL in terms that the business understand.
3. It takes a little bit of time to write the DSL.

However:

1. Doing the automation in code tends to provide faster feedback when things go wrong, and it's easier to debug it. It's also easier to include xUnit in your build.
2. It's easier to maintain a code-based DSL.
3. It takes far longer to work out how to use, say, JBehave or Cucumber, than it does to write the DSL.

As a note, the "reaction to bad TDD" is probably referring to BDD's early days, when we did it at a class level instead of at a system or application level.

I offer examples of both scenarios and unit-level behavior, written using NUnit and a DSL or Moq in C#. Works for me. Don't go for the natural-language tools unless there's clear benefit. I have extensively contributed to one of them, so feel authorised to make this recommendation without prejudice.

I wish I could give you more than +1 for calling out the difference between creation/elaboration/clarification and editing/viewing/executing/maintaining!