On 29 aug 2008, at 21:06, David C. wrote:
On Fri, Aug 29, 2008 at 1:37 PM, Bart Z. <[email protected]
wrote:
Hey list,
This is a kinda quirky
It’s only quirky-ish.
That made me laugh out loud :).
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.
| 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