Style question

[byrnejb]

The current scenario that I am working on deals with the specifics of
a form that must be completed. The question I have is: How much
detail is enough? How much is too much? Do I hide the complexity in
the steps and just provide a generic clause to the effect:

And we should see the model attributes input fields

Where does the user get to sign off on whether or not the requisite
form fields are present?

How have others handled this?

[Andrew Premdas]

2009/11/26 byrnejb <byr...@harte-lyne.ca>

--

The feature file belongs to the business, you should put the minimum amount of detail in the feature that the business will accept. This should result in features being easy for the business to read and review. Save listing of fields for step implementations and validations etc for specs. Features belong to the business, steps belong to the dev's. Finally don't write features in your steps (i.e. don't nest steps, write ruby its much more expressive.

my 2c 

Andrew

 

You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cu...@googlegroups.com.
To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.

[Matt Wynne]

I think it all comes down to how much your user / customer /
stakeholder / product-owner person trusts you. We've started getting
product owners to read the specs instead sometimes when we think it
would be wasteful to write detailed cukes for everything. Some POs
would balk at this, we're fortunate enough to have built up a good
trusting relationship with them.

cheers,
Matt

http://mattwynne.net
+447974 430184

[byrnejb]

On Nov 26, 1:00 pm, Matt Wynne <m...@mattwynne.net> wrote:

> I think it all comes down to how much your user / customer /  
> stakeholder / product-owner person trusts you. We've started getting  
> product owners to read the specs instead sometimes when we think it  
> would be wasteful to write detailed cukes for everything. Some POs  
> would balk at this, we're fortunate enough to have built up a good  
> trusting relationship with them.

I would say that trust is not an issue here (of course I would). The
only thing being considered is what works best to communicate what is
happening without losing everybody, myself particularly, in the
verbiage.

I have done the following for now. If this does not prove acceptable
then I will try something else.

In feature file:

And we should see the model attributes input fields

In step file:

When /should see the model attributes input fields/ do

ur_fields = [
'name',
'description',
'effective_from',
'superseded_after'
]
ur_fields.each do |field|
# Preface selector value with '.' for class or '#' for id
# Use class here instead of id since we may have multiple lines in
a form
expected = ".input_#{field}"
message = "Expected css attribute #{expected} was not found."
assert_select("#{expected}", true, message)
end

end

Thanks for the input.

Regards,

[Andrew Premdas]

2009/11/26 byrnejb <byr...@harte-lyne.ca>

--

You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cu...@googlegroups.com.
To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.

I'd go further than this and just fill in the form, so I wouldn't have a feature to say we should see the fields, instead we just fill in the form correctly or badly. Clearly if the fields aren't there the feature will fail anyhow so IMO 

  

  And we should see the model attributes input fields

is technical developy speak that adds nothing to expressing business need - after all forms are for filling in, not for looking at :)

 

[byrnejb]

On Nov 27, 5:53 am, Andrew Premdas <aprem...@gmail.com> wrote:

>
> > I'd go further than this and just fill in the form, so I wouldn't have a
>
> feature to say we should see the fields, instead we just fill in the form
> correctly or badly. Clearly if the fields aren't there the feature will fail
> anyhow so IMO
>

Yes, I suppose that is the best formulation; something like:

And we complete the form fields

Instead of:

>   And we should see the model attributes input fields

> after all forms are for filling in, not for looking at :)

Ah, that rather depends upon your circumstance and ones understanding
of the word form, I would say. In our business, the purpose of a
blank form is to obtain a completed one, which very many people in the
federal government have intense interest in seeing. And not just the
data but the form context as well.

Regards,

[Andrew Premdas]

2009/11/30 byrnejb <byr...@harte-lyne.ca>

Absolutely, the features should reflect the level of trust the developers have from the business and the level of detail the business wants to specify. The important thing is that the business should demand the extra detail, not the developers.

Andrew