On the other hand, earlier today my pair and I had to override a
find_by_param method. We quickly wrote it down:
def find_by_param(val)
find_by_id val
end
We were puzzled, then saw that it should be User.find_by_param.
Who'da thunk.
Pat
On Thu, Mar 13, 2008 at 10:42 PM, __iso __ <[EMAIL PR
Thanks for the info Pat. To be honest that is what I wanted to hear.
There seems to be such an importance set on the lines of code to lines
of testing ratio that it seems a person is violating some rule if the
ratio isn't high enough to the right.
The thing that bugged me when writing out the
A couple comments inline...
On Thu, Mar 13, 2008 at 5:54 PM, __iso __ <[EMAIL PROTECTED]> wrote:
> it "should call the login required" do
> controller.should_receive
> do :get
> end
This is testing too much. Just stub the call to logged_in? or whatever
> it "should call on the
On Thu, Mar 13, 2008 at 4:55 PM, Oliver Barnes
<[EMAIL PROTECTED]> wrote:
> I see. I had gotten to trying the first way you suggested (haven't
> tried the second yet):
>
> it "should assign an image to the work" do
>@work.should_receive(:image=).with(@image)
> end
>
> but I go
Hi
We have specs in our rails project other than model/view/controller ..
we have interests and lib ...
using use_transactional_fixtures = true seems fine in a spec in the m/
v/c and interests directories but not in lib
Just wondered if anyone had any quick thoughts as to why that may be???
And the other thing I am not seeing you are calling create
somewhere in the spec?
Always a good idea to post all the code :-)
Cheers
Shane
On 14/03/2008, at 12:55 PM, Oliver Barnes wrote:
> I see. I had gotten to trying the first way you suggested (haven't
> tried the second yet):
>
>
Are u stubbing Image.new and returning @image?? otherwise I think the
error is accurately complaining that it did not receive :image= with
the object that you have said.
Cheers
Shane
On 14/03/2008, at 12:55 PM, Oliver Barnes wrote:
> I see. I had gotten to trying the first way you suggested
Is it just me or does anyone else miss being able to create something
quickly. Once you start writing all the tests your time is now
increased by a factor of 10. I agree with the logic in testing, but am
I doing something wrong?
Take the simple example of a controller test for an index action th
I see. I had gotten to trying the first way you suggested (haven't
tried the second yet):
it "should assign an image to the work" do
@work.should_receive(:image=).with(@image)
end
but I got the following error:
should assign an image to the work
Mock 'Work_1002' expected :imag
On Thu, Mar 13, 2008 at 3:54 PM, Oliver Barnes
<[EMAIL PROTECTED]> wrote:
> thanks pat, it's still a good primer ;)
>
> I'm getting a better handle at it, but I'm still confused as to how to
> test assigment of associated objects. for instance, how do I test this
> (using attachment_fu)?
>
>
thanks pat, it's still a good primer ;)
I'm getting a better handle at it, but I'm still confused as to how to
test assigment of associated objects. for instance, how do I test this
(using attachment_fu)?
@work.image = @image
2008/3/11, Pat Maddox <[EMAIL PROTECTED]>:
> On Mon, Mar 10, 200
I have a helper object that I'd like to have available inside each of
my story steps, but would like to declare it *outside* all the steps.
(It knows how to create various objects in my library, then stores a
string reference to it for later steps to refer to.)
Problem is, I've tried assigning to
We've been going down this route:
http://pastie.caboo.se/165265
We use mocha for our mocking and originally we mocked out the form
builder, but the specs felt crufty. We then converted to instantiating
the FormBuilder and passing it to partials that needed it.
For the views that send in th
Thank you!
for the record, I refactored my code so the view does a form_for, and
any partials that render fields with the form builder does its own
fields_for. This makes the design cleaner and more testable. However,
I'm not sure if there's any performance cost in doing it this way
instea
I put up a short post with code snippets of using RSpec's rubyesque stories:
http://www.continuousthinking.com/2008/3/5/trying-rspec-s-rubyesque-stories
Zach
On Thu, Mar 13, 2008 at 12:21 PM, James Deville <[EMAIL PROTECTED]> wrote:
> Google for some of the stuff about story runner. It was origi
On Thu, Mar 13, 2008 at 4:21 PM, James Deville <[EMAIL PROTECTED]> wrote:
> Google for some of the stuff about story runner. It was originally not
> plain text, that's just a convenience. There are some earlier
> tutorials on David's blog about just doing stories.
I couldn't see anything on Davi
Google for some of the stuff about story runner. It was originally not
plain text, that's just a convenience. There are some earlier
tutorials on David's blog about just doing stories.
JD
On Mar 13, 2008, at 9:11 AM, Rob Holland wrote:
> Hi,
>
> Having just played with getting my first plain
Hi,
Having just played with getting my first plain text story working, I
like how it all fits together. It worked out nicely.
However, I don't feel our project needs to have stories as plain text,
in fact it's a slight hindrance for us. Is there any sensible
mechanism for doing integration testin
Hey list,
I'm refactoring some much-used functionality into a common_steps step
group. Methods like this are in there:
steps_for :common do
Given "a number of existing $types?" do |type|
@initial_item_count = type.singularize.classify.constantize.count
end
When "the user adds an
I'm not sure that this is buggy behavior, which is why I did not post it over
there. The question is if integrate_views should be a heritable trait or
not. If it is, then we almost certainly need to be able to override it--and
as a convenience method, to be able to do so locally. Implementing s
On Wed, Mar 12, 2008 at 10:19 PM, Jonathan Linowes
<[EMAIL PROTECTED]> wrote:
>
> On Mar 12, 2008, at 5:47 PM, David Chelimsky wrote:
>
> > On Wed, Mar 12, 2008 at 9:43 PM, Zach Dennis
> > <[EMAIL PROTECTED]> wrote:
> >> You can use mocha parameter matching to match on "anything" where
> >> yo
21 matches
Mail list logo
