Zach Dennis wrote:
>
> You're getting there. If anyone asks you are triangulating the target
> so you can determine exactly where it lies. To a certain extent, we
> all are. =)
I think that I am reaching the stage where I am oscillating between over
and under specifying. I am trying this stuff
On Mon, Dec 8, 2008 at 11:56 AM, James Byrne <[EMAIL PROTECTED]> wrote:
> Andrew Premdas wrote:
>>
>> TIp: When writing the step don't use - visits "/invoices/new" - use
>> visits "invoice_new_path". Use named routes and let the routing names
>> REST and resources define where you go, and think ab
Glad to be of some use. I think you're getting stuff, and your questions are
helping me get stuff and clarify some thoughts as well so thankyou for that.
2008/12/8 James Byrne <[EMAIL PROTECTED]>
> Andrew Premdas wrote:
> >
> > TIp: When writing the step don't use - visits "/invoices/new" - us
Andrew Premdas wrote:
>
> TIp: When writing the step don't use - visits "/invoices/new" - use
> visits "invoice_new_path". Use named routes and let the routing names
> REST and resources define where you go, and think about what you want
> to implement
This advice is really helpful. I was read
Well assuming its correct to start simple & general start the feature
without the concept of the client
Scenario: Manual Invoice Release
Given 4 billable charges
When I visit the pending invoices page
Then I should see ... (not sure what you should see)
Now think about those charges, w
Andrew Premdas wrote:
> Yup, very much so IMO
>
> 2008/12/5 James Byrne <[EMAIL PROTECTED]>
Bear with me. I am trying to see how one thing leads to another. Say I
have written:
Scenario: Manual Invoice Release by Client
Given 4 billable charges for client "Y"
When I visit the create
Yup, very much so IMO
2008/12/5 James Byrne <[EMAIL PROTECTED]>
> Andrew Premdas wrote:
> > Pretty hard for me to comment with so much stuff and so little context.
> > However :)
>
> My messages are quite long enough as it is I am afraid.
>
> > about a work order to produce invoices. You have to
Andrew Premdas wrote:
> Pretty hard for me to comment with so much stuff and so little context.
> However :)
My messages are quite long enough as it is I am afraid.
> about a work order to produce invoices. You have to do some design and
> thinking to produce good features. Challenge assumptions
Pretty hard for me to comment with so much stuff and so little context.
However :)
Your telling an epic story involving work orders, charges (unbilled released
and billed), invoices and transactions. So what are all these things and
what is the business value of them, can we right more focused and
Andrew Premdas wrote:
> James,
...
>
> So back to your original question where does all the detail go? Well
> acceptance tests start from the general and go to the specific, so
> detail comes further down some sort of heirarchy. Thing is you
> haven't got a hierarchy yet so you don't know where t
James,
I think this is where the art or craft comes in. Features are a great tool,
but being such a great tool I think its very easy to become tempted to
overuse them. People in software keeps on looking for the silver bullet.
They find something new, overuse it, become frustrated by it, move on t
On 4 Dec 2008, at 21:39, James Byrne wrote:
I had, at one point, the idea that, at least in the beginning, I would
do most of this detail expression in the form of feature steps. The
advice I have received has caused to reflect on whether this is a
desirable course to take. However, I can see
I need a bit of instruction. I have spent the day reading online
bloggs, tutorials, and howtos relating to BDD, RSpec and testing. I
have also spent several hours going through the cucumber spec/test
suites in an attempt to absorb some sense of how best to proceed. I am
somewhat nonplussed.
Andrew Premdas wrote:
> It seems to me that there are all sorts of implementation details in
> this story that could make your tests quite brittle. And the feature is
> definitiley a programmer writing a test, rather than a customer
Guilty as charged.
> Putting on my customer hat
>
> Scenario:
It seems to me that there are all sorts of implementation details in this
story that could make your tests quite brittle. And the feature is
definitiley a programmer writing a test, rather than a customer specifying
what they want. Putting on my customer hat
Scenario: Add location
Given I have a
Andrew Premdas wrote:
> Perhaps the creation of the join is not something that should be
> tested by a feature. This sounds to me like an implementation detail
> that would be better tested by some sort of unit test. So if your
> features want to have things in them mentioning joins, databases and
Perhaps the creation of the join is not something that should be
tested by a feature. This sounds to me like an implementation detail
that would be better tested by some sort of unit test. So if your
features want to have things in them mentioning joins, databases and
other such things then you're
James,
Hey, actual code might make it easier to help (maybe others disagree), but
here's a few things:
I'm assuming you're using rails, and has many through.
It sounds like you have something like
model: Picture (has many pagepictures, has many pages through pactures
model; Page (has many page
I am perplexed by a situation that I am creating for myself, probably
out of ignorance. I have two models connected through a join table
which itself contains information related to the join. I am testing the
creation of this join.
I already have step definitions written for one of the outside m
19 matches
Mail list logo
