On 24 Sep 2008, at 16:02, Carlos Rafael Belizón Ibáñez wrote:
Sorry, before I wrote with errors the example (it's the problem if you
are remember without code at your face). This is the correct example
with the suggestions to fix the problem:
#foo.rb
class Foo < ActiveRecord::Base
has_one :b
El jue, 25-09-2008 a las 10:27 +0100, Matt Wynne escribió:
> You're expecting the Bar class to implement an interface which
> supports you calling count -= 1 on it.
>
> Have you checked (for example, using script/console) that Bar does
> indeed offer this method? The error indicates that it do
On 25 Sep 2008, at 11:51, Carlos Rafael Belizón Ibáñez wrote:
And I got this error:
4)
Spec::Mocks::MockExpectationError in 'Alineado.cambiar_por with the
game
in play and sustitutions aviable should decrement in one the
sustitutions aviables'
Mock 'Partido_1004' received unexpected message :
El jue, 25-09-2008 a las 12:44 +0100, Matt Wynne escribió:
>
>
> Have a look at this:
> http://gist.github.com/12805
>
> When you call foo -= 1, ruby does two things:
>
> (1) asks foo for its value
> (2) tells foo to have a new value, one less than the answer it got
> back from the first ques
On Thu, Sep 25, 2008 at 8:09 AM, Carlos Rafael Belizón Ibáñez
<[EMAIL PROTECTED]> wrote:
> El jue, 25-09-2008 a las 12:44 +0100, Matt Wynne escribió:
>>
>>
>> Have a look at this:
>> http://gist.github.com/12805
>>
>> When you call foo -= 1, ruby does two things:
>>
>> (1) asks foo for its value
>>
What way it's better to test this method? Using a real instance of
game,
or using a mock?
It basically depends on how complex Game is. In this simplistic
example, there's really no harm in testing both objects together at
the same time, but nine times out of ten in the real world, you want
Thanks to both. I think that is more powerful use mocks in my project to
explain to the tribunal the benefits of use mocks and stubs against real
instances to test the code.
Thanks a lot ;).
___
rspec-users mailing list
rspec-users@rubyforge.org
http:/
Hi,
Today is a big day. I officially transitioned from manually testing by
clicking around in my app, to automated testing with RSpec + Autotest.
Yes RSpec made me find a few weaknesses in my app: while I was writing
specs for one of my models, I discovered that I had forgotten some
validations,
The problem I have with this reasoning is that the point of plain text
stories is to get more stakeholder involvement. Being able to express
shared content in plain text allows the non-programmer reader to
verify more details (for example UI interactions within a high level
story). I woul
On Thu, Sep 25, 2008 at 9:42 AM, Michael Latta <[EMAIL PROTECTED]> wrote:
> The problem I have with this reasoning is that the point of plain text
> stories is to get more stakeholder involvement. Being able to express
> shared content in plain text allows the non-programmer reader to verify more
I noticed in the RSpec documentation that "object.should raise_error"
isn't enclosed in a begin..rescue..end :
http://rspec.info/rdoc/classes/Spec/Matchers.html#M000420
However, when I use #raise_error , I have to rescue it, otherwise an
actual exception is raised and the script bails.
This
On Thu, Sep 25, 2008 at 8:01 AM, Fernando Perez <[EMAIL PROTECTED]>wrote:
>
> Also, RSpec made me discover something else: my model has some custom
> find methods. Often over time I find myself changing the name of these
> custom find methods, e.g: find_all_products -> find_available_products
>
>
On Thu, Sep 25, 2008 at 9:33 AM, Nick Hoffman <[EMAIL PROTECTED]> wrote:
> I noticed in the RSpec documentation that "object.should raise_error" isn't
> enclosed in a begin..rescue..end :
> http://rspec.info/rdoc/classes/Spec/Matchers.html#M000420
>
> However, when I use #raise_error , I have to r
On Thu, Sep 25, 2008 at 9:33 AM, Nick Hoffman <[EMAIL PROTECTED]>
wrote:
I noticed in the RSpec documentation that "object.should
raise_error" isn't enclosed in a begin..rescue..end :
http://rspec.info/rdoc/classes/Spec/Matchers.html#M000420
However, when I use #raise_error , I have to rescue
On Thu, Sep 25, 2008 at 11:56 AM, Mark Wilden <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 25, 2008 at 9:33 AM, Nick Hoffman <[EMAIL PROTECTED]> wrote:
>>
>> I noticed in the RSpec documentation that "object.should raise_error"
>> isn't enclosed in a begin..rescue..end :
>> http://rspec.info/rdoc/class
On Thu, Sep 25, 2008 at 12:33 PM, Nick Hoffman <[EMAIL PROTECTED]> wrote:
>> On Thu, Sep 25, 2008 at 9:33 AM, Nick Hoffman <[EMAIL PROTECTED]> wrote:
>> I noticed in the RSpec documentation that "object.should raise_error"
>> isn't enclosed in a begin..rescue..end :
>> http://rspec.info/rdoc/classe
On 2008-09-25, at 13:35, David Chelimsky wrote:
On Thu, Sep 25, 2008 at 9:33 AM, Nick Hoffman <[EMAIL PROTECTED]>
wrote:
Thanks for that tip, Mark. When you have a minute, would you mind
explaining
why #should needs to be sent to a Proc?
Precisely because of the problem you're experiencing.
I'm calling #stub! and #should_receive on the same method within a
class, and am finding that the method doesn't return the value given
to #stub!
216 it 'should make a map marker' do
217 mock_property = mock 'property',
218 :address => '400 Bloor Street',
219 :title
2008-09-25 13:47, Nick Hoffman:
> I'm calling #stub! and #should_receive on the same method within a
> class, and am finding that the method doesn't return the value given
> to #stub!
How about GMarker.should_receive(:new).with(foo).and_return mock_marker
--
Tero Tilus ## 050 3635 235 ## htt
On 2008-09-25, at 13:58, Tero Tilus wrote:
2008-09-25 13:47, Nick Hoffman:
I'm calling #stub! and #should_receive on the same method within a
class, and am finding that the method doesn't return the value given
to #stub!
How about GMarker.should_receive(:new).with(foo).and_return
mock_marker
On Thu, Sep 25, 2008 at 12:47 PM, Nick Hoffman <[EMAIL PROTECTED]> wrote:
> I'm calling #stub! and #should_receive on the same method within a class,
> and am finding that the method doesn't return the value given to #stub!
>
> 216 it 'should make a map marker' do
> 217 mock_property = mo
On Thu, Sep 25, 2008 at 1:04 PM, Nick Hoffman <[EMAIL PROTECTED]> wrote:
> On 2008-09-25, at 13:58, Tero Tilus wrote:
>>
>> 2008-09-25 13:47, Nick Hoffman:
>>>
>>> I'm calling #stub! and #should_receive on the same method within a
>>> class, and am finding that the method doesn't return the value g
2008-09-25 14:04, Nick Hoffman:
> I knew there was a dead simple answer to the question. Thanks, Tero.
> Apologies for the brain fart.
Np. Done the same quite a few times myself. ;)
--
Tero Tilus ## 050 3635 235 ## http://www.tilus.net/koti/tero/
___
On 2008-09-25, at 14:04, David Chelimsky wrote:
On Thu, Sep 25, 2008 at 12:47 PM, Nick Hoffman <[EMAIL PROTECTED]>
wrote:
I'm calling #stub! and #should_receive on the same method within a
class,
and am finding that the method doesn't return the value given to
#stub!
216 it 'should mak
On Thu, Sep 25, 2008 at 1:34 PM, Nick Hoffman <[EMAIL PROTECTED]> wrote:
> On 2008-09-25, at 14:04, David Chelimsky wrote:
>>
>> On Thu, Sep 25, 2008 at 12:47 PM, Nick Hoffman <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> I'm calling #stub! and #should_receive on the same method within a class,
>>> and am
Please open another thread to discuss your issue. This one is for
setting request.domain while doing tests.
--
Posted via http://www.ruby-forum.com/.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-user
Hi folks,
Wondering what the best (that is, neatest and most supported) way to
conditionally turn off some specs depending on the runtime platform.
Background: some of my specs call out to some third-party tools that
may or may not be installed on the system. I'd like to check for the
pre
On Sep 25, 2008, at 9:50 pm, Wincent Colaiuta wrote:
The following trick, calling "pending" from inside the before block,
effectively does what I want. But I'm wondering if I can count on
this behaviour going forward? What do you think?
describe 'Something' do
before do
if require
28 matches
Mail list logo
