Hey list, This is a kinda quirky 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? thanks a bunch, bartz
On Fri, Aug 29, 2008 at 1:37 PM, Bart Zonneveld <loop at superinfinite.com> wrote:> Hey list, > > This is a kinda quirkyIt''s only quirky-ish.> 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 tofeel confident your app works.>From a refactoring perspective, you should test as much as you need tofeel confident refactoring.>From a BDD perspective, the roles and permissions shouldn''t existuntil there are automated scenarios and code examples driving them into existence. 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 | (that looks right if you view in a monospace font) 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. HTH, David> thanks a bunch, > bartz > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
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
This is one of the tiny-but-amazing details that makes me excited about cucumber. (That''s one of those sentences you don''t want blogged... "No, I meant cucumber the *framework*") Aslak has done some really cool stuff here - I don''t think we''ve started to realise the power of combining tables and GWT scenarios - I have a hunch that there will be some rather nice emergent behaviour once people become familiar with it. Plus because cucumber is grammar-based, we will start discovering other complementary formats to GWT. Hmm - rather fun! 2008/8/29 David Chelimsky <dchelimsky at gmail.com>> 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. > > > 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. > > >From a refactoring perspective, you should test as much as you need to > feel confident refactoring. > > >From a BDD perspective, the roles and permissions shouldn''t exist > until there are automated scenarios and code examples driving them > into existence. > > 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 | > > (that looks right if you view in a monospace font) > > 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. > > HTH, > David > > > thanks a bunch, > > bartz > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080829/61a5ad30/attachment.html>