I’m a big fan of behavior driven development. I like getting a vague ticket, sitting down in front of the product manager and having a conversation.

Say we are building a banking application:

Me: “It says here the system should find duplicate records. What do you mean by duplicate?”
Them: “Any record with the same amount and made on the same date”
Me: *writes in a test file, in Rspec or Shoulda:

describe "finding duplicates"
   should "identify a transactions as a duplicate when the amount and date are the same as another transaction"
   should "not flag a transaction as a duplicate when the amount is the same but the date is different"
end

I then show this stub to the product owner.

Them: “Yeah, that’s right”.
Me: “what if the AICINI number is different?”

This is me asking questions based on my knowledge of the domain. Domain knowledge acquired by working in the system and implementing business domain things. (Another reason why you want to try to keep your programmers - in addition to losing their coding skills you also lose that domain knowledge from your team.)

Them: “Well, if the AICINI number is different, then it’s a different transaction

I add that to the tests. We both agree that this is a good behavioral spec for this feature.

At that point, the behavior should be a shared artifact: not just locked up in the source code repository, but shared with the product owner and business people.

Why?

• People forget what they wanted the system to do
• Avoids those times when the Product Owner is asking you, “So, how did we implement Feature X?”
• Provides a basis for any documentation that is going to get written

Behaviors should be a shared team artifact - they’re not just busy-work for programmers! Every sprint have an engineer run the script that will extract the behaviors from the source code and put them on a shared resource.

Any shared resource: file server, website… project room wall…

Writing behaviors is a different mentality from just writing tests. Imagine the tests written this way (implementation, not behavior, based)

describe "#filter_duplicates"
  should "return an array of the non-duplicate item when two transactions with the same amount and date are in the parameter array"
  should "return an array of two items when two transactions, with different amounts, are in the parameter array"
end

As programmers, we see that those describe the same functionality of the app, but those implementation level tests are not something you want to put up on the project room wall. (I really want to avoid the situation where some business person comes up and talks to me about how it would be more better if “hash filter underscore duplicates was more object oriented”.

Conclusion

Behaviors describe the business logic for the system, thus should be shared with stakeholders: they create business value (because they describe the business logic that the system implements) - in addition to preventing regressions. (But nobody outside the development team cares about this latter one, because (in general) Nobody cares about quality until it’s not there.)