Our website has detailed upgrade instructions:

http://rspec.info/upgrading-from-rspec-2/

Besides upgrading to 2.99 first, the other important thing is using
transpec.

HTH,
Myron

On Thu, Dec 31, 2015 at 4:51 PM, Cliff Rosson <[email protected]>
wrote:

> Thanks Jon. I'll give it a shot. I ran into some semantic issues when
> rspec released 3.0 some time ago but in reading the docs nothing really
> stands out on why rspec3 wouldn't work for me.
>
> On Thursday, December 31, 2015 at 4:08:09 PM UTC-8, Jon Rowe wrote:
>>
>> Full backtrace is actually designed to force a full backtrace display,
>> turning it off merely uses the default inclusion / exclusion filters, by
>> default (if I remember correctly) this includes stuff based on your working
>> directory; so if you manually add the directory (even if you use ruby to
>> generate it from the file rather than the working directory) to the
>> exclusion filter it should be removed no matter where you run the test from.
>>
>> There’s been a fair amount of work on improving this behaviour in RSpec 3
>> and given that RSpec 2 isn’t supported I heartily recommend you upgrade to
>> the latest version, if you install 2.99 first it will be relatively
>> painless!
>>
>> Cheers
>> Jon
>>
>> Jon Rowe
>> ---------------------------
>> [email protected]
>> jonrowe.co.uk
>>
>> On Friday, 1 January 2016 at 04:52, Cliff Rosson wrote:
>>
>> Versions.
>>
>> rspec (2.14.1)
>>
>> rspec-core (2.14.8)
>>
>> rspec-expectations (2.14.5)
>>
>> rspec-mocks (2.14.6)
>>
>> On Wednesday, December 30, 2015 at 9:52:45 PM UTC-8, Cliff Rosson wrote:
>>
>> Hi Folk,
>>
>> Hopefully this is a very simple question. I use RSPEC as a functional
>> test for network maintenances. It allows me to loop a series of tests
>> during a maintenance providing a clean format and notification of any
>> behavioral changes on the network.
>>
>> Often times I expect some things to fail and in an attempt to keep
>> results clean I often want to hide the full backtrace. If I run my rspec
>> with the config.full_backtrace argument set to false everything works
>> great. If I symlink the file however the backtraces return.
>>
>> I wrote this example to illustrate my issue.
>>
>> #!/usr/bin/ruby
>> require 'rspec/autorun'
>> require 'net/ping'
>>
>>
>> RSpec.configure do |config|
>>   config.full_backtrace=false
>> end
>>
>> describe "TEST A >> " do
>>   it "1:Ping is true >> " do
>>     host = Net::Ping::External.new("www.google.com")
>>     host.ping?.should be_false
>>   end
>> end
>>
>>
>> if I run this directly it works great.
>>
>> /test_rspec.rb
>>
>> F
>>
>>
>> Failures:
>>
>>
>>   1) TEST A >>  1:Ping is true >>
>>
>>      Failure/Error: Unable to find matching line from backtrace
>>
>>        expected: false value
>>
>>             got: true
>>
>>      # ./test_rspec.rb:13:in `block (2 levels) in <main>'
>>
>>
>> Finished in 0.01479 seconds
>>
>> 1 example, 1 failure
>>
>>
>> Failed examples:
>>
>>
>> rspec ./test_rspec.rb:11 # TEST A >>  1:Ping is true >>
>>
>>
>> Nice and clean output.
>> However if I symlink the file I get the full backtrace which I really
>> just would rather ignore.
>>
>> ls -l ~/bin/
>>
>> total 24
>>
>> lrwxr-xr-x  1 cliff.rosson  USERS\Domain Users  49 Dec 30 16:56
>> test_rspec -> /Users/cliff.rosson/Desktop/scratch/test_rspec.rb
>>
>>
>>
>> And run the symlink
>>
>> test_rspec
>>
>> F
>>
>>
>> Failures:
>>
>>
>>   1) TEST A >>  1:Ping is true >>
>>
>>      Failure/Error: host.ping?.should be_false
>>
>>        expected: false value
>>
>>             got: true
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-expectations-2.14.5/lib/rspec/expectations/fail_with.rb:32:in
>> `fail_with'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-expectations-2.14.5/lib/rspec/expectations/handler.rb:36:in
>> `handle_matcher'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-expectations-2.14.5/lib/rspec/expectations/syntax.rb:53:in
>> `should'
>>
>>      # /Users/cliff.rosson/bin/test_rspec:13:in `block (2 levels) in
>> <main>'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example.rb:114:in
>> `instance_eval'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example.rb:114:in
>> `block in run'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example.rb:254:in
>> `with_around_each_hooks'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example.rb:111:in
>> `run'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:390:in
>> `block in run_examples'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:386:in
>> `map'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:386:in
>> `run_examples'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:371:in
>> `run'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/command_line.rb:28:in
>> `block (2 levels) in run'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/command_line.rb:28:in
>> `map'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/command_line.rb:28:in
>> `block in run'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/reporter.rb:58:in
>> `report'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/command_line.rb:25:in
>> `run'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/runner.rb:80:in
>> `run'
>>
>>      #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/runner.rb:17:in
>> `block in autorun'
>>
>>
>> Finished in 0.01452 seconds
>>
>> 1 example, 1 failure
>>
>>
>> Failed examples:
>>
>>
>> rspec /Users/cliff.rosson/bin/test_rspec:11 # TEST A >>  1:Ping is true >>
>>
>>
>> Any-thoughts why this setting doesn't carry over when referencing the
>> symlink?
>>
>> Thanks everyone.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "rspec" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/rspec/62b49200-336a-4f42-8537-a82d536ecf8b%40googlegroups.com
>> <https://groups.google.com/d/msgid/rspec/62b49200-336a-4f42-8537-a82d536ecf8b%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "rspec" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/4f6e5a17-e808-4f4c-8cfd-f734c9bed45a%40googlegroups.com
> <https://groups.google.com/d/msgid/rspec/4f6e5a17-e808-4f4c-8cfd-f734c9bed45a%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmtnGCr5Kwc25Ss5JCa%3D_K2N-XUKj9afQNQFvPJKikBuEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to