BDD naming: when does it stop being about the user experience?

I'm drawn to MSpec with the hopes of one day sharing my test reports with non-developers*, but that is most valuable (right?) if I discuss the business (the user experience) in the test/scenario names (instead of the individual C# objects/members actually under test).

But I'm struggling, with my low-level functionality, to cite non-developer concerns in my test/scenario names. The farther the concern is from the UI, the more difficulty in naming the scenario such that it both a) is relevant to the non-developer and b) describes the low-level functionality being tested.

As you move farther and farther from the UI, is there a point at which test/scenario names just can't be shared with non-developers? I feel like the answer should be "no", because I shouldn't be testing behavior unless it's something the non-developer cares about, but I'm failing regularly enough that I'm not sure what I'm missing.

If there are obvious answers somewhere, I'd appreciate some citations/references.

* e.g. end users or other stakeholders ("stakeholders" might include future developers -- or me in a year and a half -- using these specifications to gain insight into the why of the sy开发者_如何学JAVAstem)

We normally use the word "scenario" to describe full-system, user-POV scenarios.

If you would like a word to describe class-level behaviour, try "example".

Your examples will be from the points of view of the users of your class. If those user classes want particularly developer-centric behaviour, then, yes, your examples will end up with developer-centric concerns in them.

Having said that, here are some vocabulary changes which I've found let me phrase the value I'm looking for in the most business-oriented way I can:

• returns -> tells me or gives me
• calls -> delegates, asks
• handles concurrency -> handles two things at once
• extends -> is a
• implements -> performs the role of

Basically, if you're using a developer-jargon word, imagine explaining it to someone in a few more words, then use that.

I wouldn't go overboard with it, though. The reason for using the stakeholders' domain specific terms in scenarios is because stakeholders are interested in reading and (hopefully) writing them. The audience for the class-level examples is technical, so it doesn't matter so much if we have technical concerns in them.