[rspec-users] BDDish rspecish question

Bart Zonneveld loop at superinfinite.com
Fri Aug 29 15:23:53 EDT 2008


On 29 aug 2008, at 21:06, David Chelimsky wrote:

> On Fri, Aug 29, 2008 at 1:37 PM, Bart Zonneveld <loop at superinfinite.com 
> > wrote:
>> Hey list,
>>
>> This is a kinda quirky
>
> It's only quirky-ish.

That made me laugh out loud :).

>> question for this list, but I do think it belongs
>> here. I'm currently writing an app with users with different roles.  
>> Roles
>> are sequentially so to speak, so role 2 can do everything role 1  
>> can, and so
>> on.
>> If I truly test my whole app, I should test all behaviour for each  
>> role, I
>> guess. I could solve that by doing some clever shared steps and  
>> all, but my
>> main question is this: should I test the behaviour of my entire app  
>> for each
>> role, or not, since that behaviour is embedded in the app itself?
>
>>
> From a testing perspective, you should test as much as you need to
> feel confident your app works.

This...

> From a refactoring perspective, you should test as much as you need to
> feel confident refactoring.

and this means at its least 100% coverage by stories in my book.
And since I am using stories, and stories only to drive implementation  
of features...

> From a BDD perspective, the roles and permissions shouldn't exist
> until there are automated scenarios and code examples driving them
> into existence.

there aren't any permissions in the system yet.
Most of the times a different role means a certain form field is  
available or not, or a certain action (think new/create) is allowed or  
not.
So I'm thinking of testing exhaustively for my most basic role, and  
just testing whether extra features are available and functional for  
higher roles, instead of testing the basic functionality for each and  
every role.

> The problem of multiple roles * multiple permissions (per role) can
> make this explode quite a bit. There is a relatively new feature in
> cucumber that lets you express things in a tabular format in addition
> to scenarios (think FIT, but plain text). So you can do this:
>
> Scenario: roles 3 and up can create a user
>  Given I am in the 'role 3' role
>  When I try to create a new user
>  Then I am allowed
>
> 	| role   | action            | response |
> 	| role 1 | create a new user | denied   |
> 	| role 2 | create a new user | denied   |
> 	| role 3 | create a new user | allowed  |
> 	| role 4 | create a new user | allowed  |
> 	| role 5 | create a new user | allowed  |

This means something like...

Given I have role 1
When I try to create a new user
Then  I should see a message telling me I'm not allowed to do so

Given I have role 3
When I try to create a new user
Then  I should be allowed to do so
And    there should be a new user created

right?

> For my money (even thought it's free), this is the perfect situation
> for this format, as it allows you to express a number of cases/rules
> in a clear succinct way.

It most certainly does, however, in my app I'm not really restricting  
acces on that detailed level. This looks absolutely perfect for a  
situation where role 1 can not, role 2 can, role 3 can not, and role 4  
can create a new user.

thanks for the great reply,
bartz


More information about the rspec-users mailing list