On Thu, Jan 24, 2008 at 08:25:49AM +0100, aslak hellesoy wrote:
> On Jan 24, 2008 1:04 AM, Ben Mabey <[EMAIL PROTECTED]> wrote:
> > While the original post had DRY in the subject line I don't see this as
> > a DRY issue. I see it as a visualization and maintenance issue. If I
> > add a new role a
I actually really like this idea. Very neat. Like David said the only
problem might be being able to see where the failure occurred. I think
that this problem could be solved or at least mitigated with some sort
of custom matcher though (maybe even a simple one.)
This solves the baseline cas
On Jan 24, 2008 3:47 AM, Kamal Fariz <[EMAIL PROTECTED]> wrote:
> > With 1.1.1 you can do this:
> >
> > Given "$n_users in the system" do |num_users|
> > case num_users
> > when "a user"
> ># one user case
> > when /(\d*) users/
> ># multi user case using $1
> > end
> > end
> >
> > With
On Jan 24, 2008 2:25 AM, Neil M. Young <[EMAIL PROTECTED]> wrote:
>
> some interesting viewpoints so far. How do people feel about something like
> this:
>
> Given every type of user
> When they visit account/manage
> Then only Admins and Managers should get access
>
> Given("every type of user") d
> With 1.1.1 you can do this:
>
> Given "$n_users in the system" do |num_users|
> case num_users
> when "a user"
># one user case
> when /(\d*) users/
># multi user case using $1
> end
> end
>
> With 1.1.2 you can do this:
>
> Given /(a|\d*) users? in the system/ do |num_users|
> num_u
some interesting viewpoints so far. How do people feel about something like
this:
Given every type of user
When they visit account/manage
Then only Admins and Managers should get access
Given("every type of user") do
@users = {
:admin => new_admin,
:manager => new_manager,
:super
On Jan 24, 2008 1:04 AM, Ben Mabey <[EMAIL PROTECTED]> wrote:
> While the original post had DRY in the subject line I don't see this as
> a DRY issue. I see it as a visualization and maintenance issue. If I
> add a new role and I want to test each action for it's permissions it
> would be much ea
On Jan 23, 2008 9:30 PM, Kamal Fariz <[EMAIL PROTECTED]> wrote:
> Slightly OT, but what can be done to DRY up steps? For aesthetics and
> more natural sounding stories, I often have things like
>
> Given a user in the system
>
> and
>
> Given 2 users in the system
>
> where the small change is in t
Slightly OT, but what can be done to DRY up steps? For aesthetics and
more natural sounding stories, I often have things like
Given a user in the system
and
Given 2 users in the system
where the small change is in the pluralization. What I currently do is
to have two steps that essentially
While the original post had DRY in the subject line I don't see this as
a DRY issue. I see it as a visualization and maintenance issue. If I
add a new role and I want to test each action for it's permissions it
would be much easier for a customer to go down a spread sheet and
designate within
On Jan 23, 2008 10:45 PM, Neil M. Young <[EMAIL PROTECTED]> wrote:
>
> I'm finding that I'm writing sets of very similar scenarios to check access
> permissions for each of my actions. Does anyone have suggestions on how to
> dry this up:
>
Beware that DRY has a cost. Clarity and readability.
Dav
Do all of these scenarios exist in the same story?
Should they be dried up?
Would Clarity over Cleverness apply here?
On Jan 23, 2008 4:45 PM, Neil M. Young <[EMAIL PROTECTED]> wrote:
>
> I'm finding that I'm writing sets of very similar scenarios to check
> access
> permissions for each of my ac
Neil M. Young wrote:
> I'm finding that I'm writing sets of very similar scenarios to check access
> permissions for each of my actions. Does anyone have suggestions on how to
> dry this up:
>
> Given an existing Account
> And a logged in Admin
> When the user visits account/manage
> Then he should
13 matches
Mail list logo
