With only a cursory look that looks good to me. If I have some time
later I will look more carefully and maybe suggest some refactorings,
but you look to be on the right track. The important thing is just to
practice and continually improve.
Best,
Adam
On Wed, Apr 28, 2010 at 11:37 PM, Patrick J.
> I would go a step further and say that adding an address to card is
> not very interesting (Just like iterating over addresses, adding them
> should work out of the box assuming Ruby itself isn't broken.)
Well, I ended up restructuring my code and I wrote tests for everything I
thought were impo
On Tue, Apr 27, 2010 at 4:56 PM, Patrick J. Collins
wrote:
>> If something in the code you are testing depends on the return value
>> of a method then you would use a stub. e.g.:
> Right, but what I am asking is--- if all of my "slave methods" are relying on
> stored card data from the @card inst
> If something in the code you are testing depends on the return value
> of a method then you would use a stub. e.g.:
Right, but what I am asking is--- if all of my "slave methods" are relying on
stored card data from the @card instance variable-- how is the best way to
have access to the variabl
If something in the code you are testing depends on the return value
of a method then you would use a stub. e.g.:
foo = mock(Foo)
foo.stub!(:slave_method).and_return("foo")
However, in some cases what matters is not what the method returns but
the fact that slave_method gets called. i.e.:
foo.sh
> Based on the above I think the Vcard is a good opportunity for a mock.
> That would most likely imply that you create the Vcard somewhere else
> and pass it into this method. Also, you should directly test the
Ok, and regarding mocking-- Something that is still very unclear to me is how
can I a
> Also, you should directly test the implementation of the Vcard outside of
> this spec (i.e. in it's own spec)
Could you explain what you mean by that?
Patrick J. Collins
http://collinatorstudios.com
___
rspec-users mailing list
rspec-users@rubyforge
On 27 Apr 2010, at 22:51, Patrick J. Collins wrote:
Hi,
What if they didn't? Is there a different way you could design this
so
that the interesting bits (The small methods) didn't depend so much
on
the other bits around them?
Well this is for importing vCards...
http://gist.github.com/
On Tue, Apr 27, 2010 at 2:51 PM, Patrick J. Collins
wrote:
> Hi,
>
>> What if they didn't? Is there a different way you could design this so
>> that the interesting bits (The small methods) didn't depend so much on
>> the other bits around them?
>>
>
> Well this is for importing vCards...
> http:/
Hi,
> What if they didn't? Is there a different way you could design this so
> that the interesting bits (The small methods) didn't depend so much on
> the other bits around them?
>
Well this is for importing vCards...
http://gist.github.com/381384
So for example, I would like to just make a sp
On Tue, Apr 27, 2010 at 2:20 PM, Patrick J. Collins
wrote:
> Hi everyone,
>
> I still am on my quest to understand Rspec, and I have a few new questions...
>
> If I have a "complex" method which calls other methods, say something like:
>
> -
>
> class Foo
>
> def complex_method
> setu
Hi everyone,
I still am on my quest to understand Rspec, and I have a few new questions...
If I have a "complex" method which calls other methods, say something like:
-
class Foo
def complex_method
setup
setup_something_else
mini_method1
mini_method2
12 matches
Mail list logo
