Featured post
BDD naming: when does it stop being about the user experience? -
i'm drawn mspec hopes of 1 day sharing test reports non-developers*
, valuable (right?) if discuss business (the user experience) in test/scenario names (instead of individual c# objects/members under test).
but i'm struggling, low-level functionality, cite non-developer concerns in test/scenario names. farther concern ui, more difficulty in naming scenario such both a) relevant non-developer , b) describes low-level functionality being tested.
as move farther , farther ui, there point @ test/scenario names can't shared non-developers? feel answer should "no", because i shouldn't testing behavior unless it's non-developer cares about, i'm failing regularly enough i'm not sure i'm missing.
if there obvious answers somewhere, i'd appreciate citations/references.
*
e.g. end users or other stakeholders ("stakeholders" might include future developers -- or me in year , half -- using these specifications gain insight why of system)
we use word "scenario" describe full-system, user-pov scenarios.
if word describe class-level behaviour, try "example".
your examples points of view of users of class. if user classes want particularly developer-centric behaviour, then, yes, examples end developer-centric concerns in them.
having said that, here vocabulary changes i've found let me phrase value i'm looking in business-oriented way can:
- returns -> tells me or gives me
- calls -> delegates, asks
- handles concurrency -> handles 2 things @ once
- extends -> a
- implements -> performs role of
basically, if you're using developer-jargon word, imagine explaining in few more words, use that.
i wouldn't go overboard it, though. reason using stakeholders' domain specific terms in scenarios because stakeholders interested in reading , (hopefully) writing them. audience class-level examples technical, doesn't matter if have technical concerns in them.
- Get link
- X
- Other Apps
Comments
Post a Comment