Tagged: tdd

I think there exists some value in a direct mapping between your software's system roles, the functions provided to each role, and the tests one writes to verify that each type of user can perform each task with the same desired outcome. Albeit a simplistic (or trite) view of the process of creating software, I think such a mapping can actually define your project's work items. Let me explain. At the end, there's question. I'm really interested in what the community thinks of this approach, welcome any outright flames, and of course encourage critical-yet-considerate dialog. 

So let's say you sit down with your product owner for a planning meeting to iron out your stories together. Suppose you come up with a few roles for your system - Admin, Editor, User - and you define some stories and expectations for the system based on those roles.

• As an Admin I expect to be able to create new user accounts 
• As an Editor I expect to be able to review the content of blog posts created by Users for content I deem questionable. For said posts I expect to have the right to change or delete the content. 
• As a User I expect to be able to create blog posts, which must contain a title, a body, and a list of tags

And so on. Considering that list of 4 stories one could ritualistically create tests that verified the functionality would take place. The following code might portray some of the tests a developer might be handed and told "when these pass you're good, we're done, etc" (the person would actually have to say "et-cet-er-UH" for this to be relevant, but I digress).

[Test]
public void Can_Admin_Create_New_User_Accounts()
{
}
[Test]
public void Can_Editor_Edit_Blog_Post()
{
}
[Test]
public void Can_Editor_Delete_Blog_Post()
{
}
[Test]
public void Does_System_Reject_Blog_Post_Without_Title_or_Body()
{
}
[Test]
public void Can_User_Create_Blog_Post()
{
}

Here's the question. Sure, this is a bit simplistic, a bit trite, and overall a happy zen land for the TDD/Domain-ish developer. It also infers a bit of responsibility on the whole team to pretty clearly define things [sic] up front and as a result implies your workplace is just left field of Narnia. Yeah, that's true and all, but would this approach work for even the mildest and greenfieldyest of projects? If we look at the Agile process like a third grader and the team really does work together to achieve a common success, this approach might actually work, right?