On Mon, Aug 24, 2009 at 6:09 PM, jg wrote:
> I have a very fairly simple spec
>
> it "should assign an instance variable" do
> get 'new'
> assigns[:city].should == City.new
> end
>
> In my controller
>
> def new
> �...@city = City.new
> end
>
> but when I run it, I get
>
> 'CitiesController GET
I have a very fairly simple spec
it "should assign an instance variable" do
get 'new'
assigns[:city].should == City.new
end
In my controller
def new
@city = City.new
end
but when I run it, I get
'CitiesController GET 'new' should assign an instance variable' FAILED
expected: #,
Yeah, I'm an idiot. I was missing the whole 'it "should do something"
do' line.
Thanks for getting back so quick though!
On Aug 23, 11:30 pm, David Chelimsky wrote:
> On Sun, Aug 23, 2009 at 8:57 PM, Jesterman81 wrote:
> > Greetings,
>
> > I am trying to use the mock method in rspec and it retu
On 24 Aug 2009, at 22:00, Gregory Hnatiuk wrote:
Thanks.
From a best-practices perspective, should a spec which changes
something global change it back afterwards in general, or should it be
the responsibility of a given spec to ensure the environment is
appropriate itself before running exa
Thanks.
>From a best-practices perspective, should a spec which changes
something global change it back afterwards in general, or should it be
the responsibility of a given spec to ensure the environment is
appropriate itself before running examples (or both)?
It seems like changing something glo
On Mon, Aug 24, 2009 at 2:19 PM, Gregory Hnatiuk wrote:
> What is the expected/intended behavior for the scope of class instance
> variables when running multiple specs?
>
> It appears that setting a class instance variable in one spec will
> affect it in a second spec run like so:
>
> http://gist.
What is the expected/intended behavior for the scope of class instance
variables when running multiple specs?
It appears that setting a class instance variable in one spec will
affect it in a second spec run like so:
http://gist.github.com/174018
running `spec spec1_spec.rb spec2_spec.rb` or `s
On Mon, 24 Aug 2009 10:56:00 -0700, you wrote:
>This will work (I'll go update the code now) but it still leaves the
>problem I mentioned that if you are unfamiliar with the vagaries of
>floating point math -- or even if you momentarily forget -- then using
>== will occasionally mysteriously fail.
> What about a helpful error message when "should ==" fails on floats:
>
> expected 98.6, got 98.6
>
> The expected and actual may appear to be the same due to Ruby's string
> representation of floating point numbers. For floating point math, we
> recommend using the be_close() matcher instead.
>
>
On Mon, Aug 24, 2009 at 12:56 PM, Alex Chaffee wrote:
> ...and, while I was composing that message, Brian sent me the following:
>
>> Rspec does provide the be_close matcher. See cheat rspec.
>
> @temperature.ctof(37).should be_close(98.6, 0.1)
>
> This will work (I'll go update the code now) but i
On 24 Aug 2009, at 18:56, Alex Chaffee wrote:
== will occasionally mysteriously fail. So my proposal remains: can
the == matcher do be_close(x, 0.01) for floats? Arguments pro
and con?
The "problem" you describe is with Ruby's == operator, not with RSpec.
The == matcher must agree with
...and, while I was composing that message, Brian sent me the following:
> Rspec does provide the be_close matcher. See cheat rspec.
@temperature.ctof(37).should be_close(98.6, 0.1)
This will work (I'll go update the code now) but it still leaves the
problem I mentioned that if you are unfamilia
Check out the following gist: http://gist.github.com/173975
It's from a Test-Driven Intro To Ruby class I'm working on. Looks good, right?
Not so fast. Check out this spec:
it "converts body temperature" do
t = @temperature.ctof(37)
(t*10).round.should == 986
end
Why do we
13 matches
Mail list logo
