On Tue, Jul 21, 2009 at 2:05 AM, Barun Singh wrote:
> This isn't a question of refactoring; I can
> easily refactor the method as you describe but this doesn't resolve the
> issue (indeed, it just leads to an increased number of public methods in the
> model with no real benefit).
Why would they h
I certainly appreciate the thoughtful and lengthy reply, but I think it
misses the main part of my problem -- perhaps my original explanation of my
issue was lacking in clarity. This isn't a question of refactoring; I can
easily refactor the method as you describe but this doesn't resolve the
issu
On Mon, Jul 20, 2009 at 11:05 PM, Chris
Sund wrote:
>
> I am finally to the point in the rspec book where it describes how to
> implement controller specs, so I thought what the heck, I'll give it a
> try.
Heh. Points to you for ambition! You might not have realized this
(because the RSpec book
On Mon, Jul 20, 2009 at 8:33 PM, Barun Singh wrote:
>
> I want to find a way to write a spec for this method that does both of these
> things:
> (1) stub out the do_something method (that method has its own specs)
> (2) not stub out the logic in the else statement, (there is some complex
> logic
Chris Sund wrote:
Hey Everyone,
I am finally to the point in the rspec book where it describes how to
implement controller specs, so I thought what the heck, I'll give it a
try. I have an app I have been working on (Inside out) that I needed
to get test specs written for before I continue on wit
On Jul 20, 2009, at 6:58 PM, David Chelimsky wrote:
So for me this is not an either/or question. Each underlying component
has a responsibility, and the result of the three components doing the
right thing adds up to the application behaving correctly.
I'd also add that, for me, the cucumber
Hey Everyone,
I am finally to the point in the rspec book where it describes how to
implement controller specs, so I thought what the heck, I'll give it a
try. I have an app I have been working on (Inside out) that I needed
to get test specs written for before I continue on with the app. Now
that
I have a recursive class-level method that I'd like to spec. the logic of
it essentially does something like this:
def self.mymethod(inputs)
If x =
x.do_something
else
mymethod(inputs)
end
end
I want to find a way to write a spec for this method that does both of these
things
On Mon, Jul 20, 2009 at 5:58 PM, David Chelimsky wrote:
> On Mon, Jul 20, 2009 at 5:30 PM, Marcelo de Moraes
> Serpa wrote:
>> Hello list,
>>
>> I have an example/spec that relates to the Product#index view and
>> says "it should display only the active products". The thing is the
>> logic to filt
Marcelo,
My take on this is that if your business user wants to make sure that there
are only active products displayed, then it should be in a story.
There may be a question about speccing the implementation; however if you
are using a named scope - you might argue that you are testing a library
On Mon, Jul 20, 2009 at 5:30 PM, Marcelo de Moraes
Serpa wrote:
> Hello list,
>
> I have an example/spec that relates to the Product#index view and
> says "it should display only the active products". The thing is the
> logic to filter the active products should be in the model, and not on
> the v
Hello list,
I have an example/spec that relates to the Product#index view and
says "it should display only the active products". The thing is the
logic to filter the active products should be in the model, and not on
the view, since the view should be "dumb". I just realized that, and
what I thin
12 matches
Mail list logo
