On 29 aug 2008, at 21:06, David Chelimsky wrote:
On Fri, Aug 29, 2008 at 1:37 PM, Bart Zonneveld <[EMAIL PROTECTED]
> 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
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
