On Sun, Mar 1, 2009 at 11:07 AM, Mark Wilden wrote:
>
> Just be careful when when basing durations from "now" that daylight
> savings time doesn't affect anything.
Like it did today, when two specs that used 'Time.now.advance(:hours
=> 24).utc' started failing.
///ark
___
On Mar 7, 2009, at 5:49 AM, Phlip wrote:
Scott Taylor wrote:
Go and file a bug report then, but if you only give this level of
detail, the bug will never get fixed.
I am not reporting any bug in RSpec. Read the Subject line.
I think I know why RSpec has an option (-b) to turn off incomplet
On Sat, Mar 7, 2009 at 8:50 AM, David Chelimsky wrote:
> On Fri, Mar 6, 2009 at 4:02 PM, rockrep wrote:
>> Hi David, all:
>>
>> I just recently upgraded to Rails 2.3.1RC2 (Mac OS.X 10.5.6, ruby
>> 1.8.7 (2008-08-11 patchlevel 72) [i686-darwin9]) and have been
>> dilligently following the instruc
On Fri, Mar 6, 2009 at 4:02 PM, rockrep wrote:
> Hi David, all:
>
> I just recently upgraded to Rails 2.3.1RC2 (Mac OS.X 10.5.6, ruby
> 1.8.7 (2008-08-11 patchlevel 72) [i686-darwin9]) and have been
> dilligently following the instructions for upgrading rspec and rspec-
> rails according to:
>
On Sat, Mar 7, 2009 at 12:01 AM, mudphone wrote:
> David,
>
> Thanks for your help and for setting me straight. I am running Rails
> 2.2.2 and rspec 1.1.12.
>
> I started a new Rails project as well, and have discovered that my
> problem is that I have root-level model class, with the same name a
David,
Thanks for your help and for setting me straight. I am running Rails
2.2.2 and rspec 1.1.12.
I started a new Rails project as well, and have discovered that my
problem is that I have root-level model class, with the same name as
the nested directory. It looks like this:
app/models/thing
Thanks.
On 6 Mar, 23:42, Pat Nakajima wrote:
> I've posted it on this list before, but if you're writing view tests, check
> out
> Elementor:http://pivotallabs.com/users/patn/blog/articles/608-better-view-testi
> It provides a much cleaner way of asserting on markup, and doesn't require
> yo
Hi David, all:
I just recently upgraded to Rails 2.3.1RC2 (Mac OS.X 10.5.6, ruby
1.8.7 (2008-08-11 patchlevel 72) [i686-darwin9]) and have been
dilligently following the instructions for upgrading rspec and rspec-
rails according to:
http://wiki.github.com/dchelimsky/rspec/rails-with-rspec-gems
script/spec -b /path/to/spec.rb will give a full backtrace. You can
also add --backtrace to your spec.opts.
Cheers,
Chris
Yay! txkbye!
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Scott Taylor wrote:
Go and file a bug report then, but if you only give this level of
detail, the bug will never get fixed.
I am not reporting any bug in RSpec. Read the Subject line.
I think I know why RSpec has an option (-b) to turn off incomplete stack traces.
The various Ruby editors ha
Bira, and Ben,
Bira wrote:
> David and Ben,
>
> Thank you very much for your advice :).
Hi, Alexis here from RabbitMQ. +1 to what Ben said.
Ben - that's a really nice project you've set up there Ben. Could you
introduce it on the rabbitmq-discuss list some time perhaps?
Bira - may I leave y
2009-03-07 01:17, Phlip:
> So the question becomes: Why do we sometimes get the correct stack
> trace and sometimes we don't?
What do you mean by "correct"? To my knowledge you havent posted any
single somehow incorrect stack trace. If you by "correct" mean
"complete", I dare to ask if you do sc
2009-03-07 01:12, Phlip:
> Test::Unit::TestCase said the error was ~20 layers deeper - but
> exactly below the same to_xml() call as RSpec indicated. RSpec threw
> the stack trace away.
You could have told that right away. :-/
It seems I cant reproduce the trace mangling. Do have steps to
repro
Phlip wrote:
Tero Tilus wrote:
Line 192 contains neither a stray nil nor a method 'macro'.
So what exactly _is_ there? Do you know that particular line causes
(or noes not cause) the error?
Test::Unit::TestCase said the error was ~20 layers deeper - but
exactly below the same to_xml() c
Nope. Try 1/0 inside a sub-method - you won't get a stack trace to it,
right?
Usually it does:
>> def foo
>> 1/0
>> end
=> nil
>> def bar
>> foo
>> end
=> nil
>> bar
ZeroDivisionError: divided by 0
from (irb):43:in `/'
from (irb):43:in `foo'
from (irb):46:in `bar'
fr
def really_div_by_zero
1/0
end
def div_by_zero
really_div_by_zero
end
it 'should trace my stack' do
div_by_zero
end
And that hits the correct line:
ZeroDivisionError in 'Whatever should trace my stack'
divided by 0
spec/blog_mind_map_spec.rb:192:in `/'
spec/blog_mind_ma
On Sat, Mar 7, 2009 at 8:25 AM, Scott Taylor wrote:
> Phlip wrote:
The question is why did RSpec throw away the backtrace? Am I the first
person in history to hit a programming error inside RSpec??
script/spec -b /path/to/spec.rb will give a full backtrace. You can
also add --backt
Tero Tilus wrote:
Line 192 contains neither a stray nil nor a method 'macro'.
So what exactly _is_ there? Do you know that particular line causes
(or noes not cause) the error?
Test::Unit::TestCase said the error was ~20 layers deeper - but exactly below
the same to_xml() call as RSpec i
Phlip wrote:
The question is why did RSpec throw away the backtrace? Am I the
first person in history to hit a programming error inside RSpec??
Nope, but this probably isn't one of them.
I said it wrong. The complete venting goes "Am I the first person in
history to use RSpec, and then hit
2009-03-06 22:32, Phlip:
> Line 192 contains neither a stray nil nor a method 'macro'.
So what exactly _is_ there? Do you know that particular line causes
(or noes not cause) the error?
In situations like this I usually pop to debugger right before the
problematic line and then poke around (ev
20 matches
Mail list logo
