Thanks!

@Joey
Hmm… I’m not sure I get the “when given” syntax, but I think I understand what you’re trying to get at. For our team.. under these conditions IS establishing the context.

So we read them as “when creating a new account for a user with a valid submission it should inform the user that the account was created”

My experience with this style of testing so far has been that the “jump around” has decreased. Once you understand the context you read the “test” and should be able to immediately understand what is failing.

Regardless of what team you jump into there’s always going to be time needed understanding that teams style of development. But you bring up some valid points, that I will definitely have to think over. Thanks for your input!

So I understand the readability aspect of it and sharing the same language as the business user. But I believe you are forgetting the “other” user, “me”, the next developer that will maintain this codebase. If I am unaware of the Context/Specification style and just coming into your project, it seems out of order.

- When given
- it should
- under these conditions
- because of

That doesn’t read well to me as the developer … think of the flow of tests it is going to run.

- When given
- Under these conditions
- because of
- it should

It reads well for the business user and the flow of the tests as well for a maintenance developer.

Remember, tests are supposed to be easy to understand! If I have to jump around the code to figure out the flow, that is a “test smell” to me.

A concrete example that’s not completely trivial would I think be beneficial. Trying to break into BDD there just aren’t that many examples to draw from that aren’t completely synthetic.