sconover / wrong Goto Github PK

Hi Steve,

Having written assert_* and should bla for 12 years, I was quite curious about the "Wrong" way. So far, so good:)

Googling "wrong" related articles is difficult, would you change the name?
Something more googable like Wronga, wrongwrong, wrong-assertions, ...

Cheers,

Jean-Michel

From the wrong README:

And in what human language is "should greater than" a valid phrase?

It's not in human languages, or RSpec. The correct use of ">" is:

BleuCheese.new.smell.should be > 9000

You may still prefer assert { BleuCheese.new.smell > 9000 }, but at least you're preferring it over the right thing.

FWIW, what's in the wrong README will work, but that's only to support people who don't bother to RTFM: http://rubydoc.info/gems/rspec-expectations#Comparisons

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

  spec.license = 'MIT'
  # or
  spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can imagine, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.

I found an odd behavior when using eventually and should_not be_nil.

it "should work with be_nil" do
    found = "X"
    eventually {
      found.should_not be_nil
    }
end

Error message is:

Expected found.should_not(be_nil), but
found is "X"
be_nil is #<RSpec::Matchers::BuiltIn::BeNil:0x007ff531aea8e8
@expected=nil>

Am I doing anything wrong?

I tried the first example in the README on Ruby 2.1.4p265, and it doesn't produce the output I expected from the description in the README. The code sample is the following:

require 'wrong'

include Wrong

assert { 1 == 1 }

assert { 2 == 1 }

It produces the following output:

/Users/moonglum/.rvm/gems/ruby-2.1.4/gems/wrong-0.7.1/lib/wrong/assert.rb:82:in `aver': Expected (2 == 1) (Wrong::Assert::AssertionFailedError)
        from /Users/moonglum/.rvm/gems/ruby-2.1.4/gems/wrong-0.7.1/lib/wrong/assert.rb:34:in `assert'
        from test.rb:7:in `<main>'

I would expect an output like this:

 ==> Expected (2 == 1), but 2 is not equal to 1

I'm using wrong 0.7.1 freshly installed from RubyGems. Commenting out the last line doesn't give me any output at all.

Ruby 2.6 is introducing integrated ruby parsing and AST API. This will help eliminate dependencies and may improve performance. https://ruby-doc.org/core-2.6.0.preview2/RubyVM/AST.html

This will remove the ParseTree (and maybe RubyInline?) dependencies, as well as allow Ruby 1.9 syntax to be used inside Wrong assert blocks.

We can't release it quite yet because (a) they're not released yet (except in alpha) and (b) there's a bug in ruby_parser that conflicts with the "d" method - seattlerb/ruby_parser#59

Most of the work is done though; checked in to my fork as dbb95a9

make sure Wrong works with new ruby2ruby

http://blog.zenspider.com/2011/09/ruby2ruby-version-130-has-been.html

Using Rails 4.1 (maybe also 4.0) and Rspec-rails 2.99, the assert method does not work.

ArgumentError:
       wrong number of arguments (0 for 1..2)

I used this fix:

if RSpec.const_defined? :Rails
  require 'rails/version'
  if Rails::VERSION::MAJOR == 4
    module RSpec::Rails::MinitestAssertionAdapter::ClassMethods
      def define_assertion_delegators_with_removed
        define_assertion_delegators_without_removed
        class_eval do
          remove_method :assert
        end
      end
      alias_method_chain :define_assertion_delegators, :removed
    end
  end

in addition to the RAILS::VERSION::MAJOR == 3 part in https://github.com/sconover/wrong/blob/master/lib/wrong/adapters/rspec.rb#L7

Just changing the == 3 to >=3 did not work because:

gems/activesupport-4.1.0.beta1/lib/active_support/concern.rb:126:in `included': 
Cannot define multiple 'included' blocks for a Concern (ActiveSupport::Concern::MultipleIncludedBlocks)

This is, why I used the alias method chain.

Would be great to see missing tags/releases for the corresponding gem files here, too.

When I execute an rspec test with zeus and it contains an "assert" block, the ruby process's cpu usage skyrockets to 100% and it drops into an infinite loop. When I execute the same test with pure rspec everything works fine.

The README says you can alias assert with expect when using RSpec. This actually doesn't work because rspec-expectations already defines expect (as an alias for lambda). The outcome is that all examples pass whether they should or not.

RSpec recently added a hook to configure the assertion/expectation library to be either rspec-expectations, stdlib (t/u assertions on 1.8, minitest assertion on 1.9), or both. I tried setting this to use stdlib so rspec-expectations wouldn't be loaded (and define expect, but then there were errors because wrong assigns failure_class the value RSpec::Expectations::ExpectationNotMetError, which lives (as its name suggests) in rspec-expectations.

Since this isn' t working as advertised, it'd be great if you changed the README to exclude the bit about aliasing assert with expect.

Once that's done, I'd like to get this working and am happy to collaborate with you to do so. The question is what belongs where? One possibility is for RSpec to expose a configuration option that turns off the lambda, expect alias. Another is for RSpec to expose a better extension point for this sort of integration - something like the mock framework adapters. I'm sure there are several other approaches we could take.

WDYT?

#30 is needed to work with cucumber. It's merged into master, but a new version hasn't been released.

RSpec indents when printing the exception message, which means that the line should wrap 8 characters (or so) sooner than it does now. Probably the same for other test frameworks too.

a = [1,2,3,4]

assert{a.all?{|i| i<4}}

Wrong::Assert::AssertionFailedError: Expected a.all? { |i| (i < 4) }, but
    i raises NameError: undefined local variable or method `i' for main:Object

    from /Users/bradphelan/.rvm/gems/ruby-1.9.2-p180/gems/wrong-0.5.4/lib/wrong/assert.rb:72:in `aver'
    from /Users/bradphelan/.rvm/gems/ruby-1.9.2-p180/gems/wrong-0.5.4/lib/wrong/assert.rb:34:in `assert'
    from (irb):12
    from /Users/bradphelan/.rvm/rubies/ruby-1.9.2-p180/bin/irb:16:in `<main>'

also

 assert{a.all?{|i| i<4}==true}
Wrong::Assert::AssertionFailedError: Expected a.all? { |i| (i < 4) }, but
    i raises NameError: undefined local variable or method `i' for main:Object

    from /Users/bradphelan/.rvm/gems/ruby-1.9.2-p180/gems/wrong-0.5.4/lib/wrong/assert.rb:72:in `aver'
    from /Users/bradphelan/.rvm/gems/ruby-1.9.2-p180/gems/wrong-0.5.4/lib/wrong/assert.rb:34:in `assert'
    from (irb):12
    from /Users/bradphelan/.rvm/rubies/ruby-1.9.2-p180/bin/irb:16:in `<main>'

Hey y'all - if you're going to dis another library to make yours look good, at least get the syntax of the other lib correct.

BlueCheese.new.smell.should be > 9000

Cheers,
David

So I have this kinda crazy idea for integrating wrong with rspec:

describe User do
  it "has the read-only role by default" do
    User.new.role == Role::READ_ONLY
  end
end

The idea is that, if configured to do so, rspec would forward the block passed to it to assert (or maybe wrong could expose a function to support similar w/o having to include anything). This way you don't even need to fuss over "assert" v "expect" - the block passed to it has to conform to the same rules as a block passed to wrong's assert.

As a preliminary experiment, I tried this:

require 'wrong/adapters/rspec'

describe "something" do
  it "does something" do
    assert do
      x = 5
      y = 3
      x == y
    end
  end

  it "does something else" do
    x = 5
    y = 3
    assert { x == y }
  end
end

When I ran this I got the following output:

FF

Failures:

  1) something does something
     Failure/Error: assert do
       Expected x = 5
       y = 3
       (x == y)
       , but
           (x == y) raises NameError: undefined local variable or method `x' for #<RSpec::Core::ExampleGroup::Nested_1:0x007fe41bdd35e0>
           x raises NameError: undefined local variable or method `x' for #<RSpec::Core::ExampleGroup::Nested_1:0x007fe41bdd35e0>
           y raises NoMethodError: undefined method `yaml' for nil:NilClass
     # ./example_spec.rb:5:in `block (2 levels) in <top (required)>'

  2) something does something else
     Failure/Error: assert { x == y }
       Expected (x == y), but
           x is 5
           y is 3
     # ./example_spec.rb:15:in `block (2 levels) in <top (required)>'

As you can see, wrong does a great job of providing feedback for the example with the single line block, but the feedback for the multi-line block is a bit useless. So the question is: can wrong be modified to only care about the last statement in the block? Of course, the other question is: do you think this idea is interesting enough to try to make it happen?

Given the following failing example in failing_example.rb

require 'wrong/adapters/rspec'

describe "a block arg in a failing assertion" do
  it "raises a NameError :(" do
    assert { [].each {|v|} != [] }
  end
end

When I run rspec failing_example.rb

Then I get this error:

F

Failures:

  1) a block arg in a failing assertion raises a NameError :(
     Failure/Error: assert { [].each {|v|} != [] }
       Expected [].each { |v| }.!=([]), but
           (v) raises NameError: undefined local variable or method `v' for #<RSpec::Core::ExampleGroup::Nested_1:0x007f938a0d1ef0>
     # ./failing_example.rb:5:in `block (2 levels) in <top (required)>'

The example should fail, that's not the problem. The problem is the failure message should indicate that the values were not equal, not a NameError on v

I'm having issues including Wrong in a trivial greenfield test application. Though this is more "support" than "issue", I'm guessing whatever the right answer is means the docs need updating.

First, get set up:

$ rails -v
Rails 3.2.3
$ rails new test_app
$ cd test_app/
$ rake db:create
$ rails g scaffold Post title:string body:text
$ rake db:migrate

This will give you a trivial new app with some tests to run:

$ rake test:functionals
Run options: 

# Running tests:

.......

Finished tests in 0.154397s, 45.3377 tests/s, 64.7681 assertions/s.

7 tests, 10 assertions, 0 failures, 0 errors, 0 skips

Okay, great. Now add gem "wrong" to the Gemfile, and bundle install.

Then, add wrong to your test/test_helper.rb file like so: https://gist.github.com/61af0b2b0431e61c1258

Crack open your test/functional/posts_controller_test.rb and add two trivial wrong-style assertions: https://gist.github.com/e75c14cf155e5decdf22

Now run your tests and enjoy your errors:

$ rake test:functionals

# Running tests:

...EE..

Finished tests in 0.160737s, 43.5494 tests/s, 62.2134 assertions/s.

  1) Error:
test_should_get_index(PostsControllerTest):
ArgumentError: wrong number of arguments (0 for 1)
[...]

  2) Error:
test_should_get_new(PostsControllerTest):
ArgumentError: wrong number of arguments (0 for 1)
[...]

7 tests, 10 assertions, 0 failures, 2 errors, 0 skips

The suite is seemingly still trying to use MiniTest's assert, which takes 1 argument.

Thoughts?

I have a test file that is comprised entirely of wrong assertions (wrong_wrong.rb):

require 'active_support'
require 'wrong'

class WrongWrongTest < ActiveSupport::TestCase
  include Wrong

  def test_if_wrong_is_right
    assert{ true }
  end

  def test_if_wrong_is_right_about_being_wrong
    assert{ false }
  end
end

I run the tests:

~/tmp $ testrb wrong_wrong.rb
Loaded suite WrongWrongTest
Started
E

Error:
test_if_wrong_is_right_about_being_wrong(WrongWrongTest):
Wrong::Assert::AssertionFailedError: Expected false
    /Users/barry/.rvm/gems/ree-1.8.7-2010.02/gems/wrong-0.6.0/lib/wrong/assert.rb:72:in `aver'
    /Users/barry/.rvm/gems/ree-1.8.7-2010.02/gems/wrong-0.6.0/lib/wrong/assert.rb:34:in `assert'
    /Users/barry/tmp/wrong_wrong.rb:12:in `test_if_wrong_is_right_about_being_wrong'
    /Users/barry/.rvm/gems/ree-1.8.7-2010.02/gems/activesupport-3.1.0/lib/active_support/testing/setup_and_teardown.rb:67:in `__send__'
    /Users/barry/.rvm/gems/ree-1.8.7-2010.02/gems/activesupport-3.1.0/lib/active_support/testing/setup_and_teardown.rb:67:in `run'
    /Users/barry/.rvm/gems/ree-1.8.7-2010.02/gems/activesupport-3.1.0/lib/active_support/callbacks.rb:390:in `_run_setup_callbacks'
    /Users/barry/.rvm/gems/ree-1.8.7-2010.02/gems/activesupport-3.1.0/lib/active_support/callbacks.rb:81:in `send'
    /Users/barry/.rvm/gems/ree-1.8.7-2010.02/gems/activesupport-3.1.0/lib/active_support/callbacks.rb:81:in `run_callbacks'
    /Users/barry/.rvm/gems/ree-1.8.7-2010.02/gems/activesupport-3.1.0/lib/active_support/testing/setup_and_teardown.rb:65:in `run'



Finished in 0.005216 seconds.

2 tests, 0 assertions, 0 failures, 1 errors, 0 pendings, 0 omissions, 0 notifications
0% passed

383.44 tests/s, 0.00 assertions/s

Notice how the one failure shows in the results as 1 errors. But the successful assertion does not show, rather 0 assertions.

System info:

~/tmp $ gem list | grep wrong
wrong (0.6.0, 0.5.6, 0.5.4, 0.5.0, 0.4.5)
~/tmp $ gem list | grep test-unit
test-unit (2.4.0, 2.3.2, 2.2.0, 2.1.2, 1.2.3)
~/tmp $ gem list | grep activesupport
activesupport (3.1.0, 3.0.10, 3.0.6, 3.0.5, 3.0.4, 3.0.3, 3.0.1, 3.0.0, 3.0.0.rc, 2.3.8, 2.3.5)

Am I nuts?

Requiring Wrong and starting debug in RubyMine produces NameError:

undefined method `evaluate' for class `IRB::Context' (NameError)

Stacktrace:

/Users/***/.rbenv/versions/2.3.2/lib/ruby/gems/2.3.0/gems/wrong-0.7.1/lib/wrong/irb.rb:4:in `<class:Context>'
/Users/***/.rbenv/versions/2.3.2/lib/ruby/gems/2.3.0/gems/wrong-0.7.1/lib/wrong/irb.rb:3:in `<module:IRB>'
/Users/***/.rbenv/versions/2.3.2/lib/ruby/gems/2.3.0/gems/wrong-0.7.1/lib/wrong/irb.rb:2:in `<top (required)>'
/Users/***/.rbenv/versions/2.3.2/lib/ruby/gems/2.3.0/gems/wrong-0.7.1/lib/wrong.rb:12:in `require'
/Users/***/.rbenv/versions/2.3.2/lib/ruby/gems/2.3.0/gems/wrong-0.7.1/lib/wrong.rb:12:in `<top (required)>'
/Users/***/*/file.rb:10:in `require'

So it blocks debugging completely.

This is closely related to #21.

In his comment on that issue, @alexch pointed out that variables inside an assert block might be out of scope when the gem tries to introspect them. This can make for misleading output. An example using Test::Unit:

  test "wrong block example" do
    assert do
      (1..5).all? do |num|
        num.in? 1..4
      end
    end
  end

This test fails with the following output:

===============================================================================
Failure:
  Expected (1..5).all? { |num| num.in?((1..4)) }, but
      num.in?((1..4)) raises NameError: undefined local variable or method `num' for test_wrong_block_example(WorkShelfTest):WorkShelfTest
      num raises NameError: undefined local variable or method `num' for test_wrong_block_example(WorkShelfTest):WorkShelfTest
      (1..4) is 1..4
test_wrong_block_example(WorkShelfTest)
test/unit/work_shelf_test.rb:7:in `block in <class:WorkShelfTest>'
===============================================================================

A test failure like this had me scratching my head for several minutes today, because I couldn't see how num could possibly be undefined.

Perhaps the solution is not to report such NameErrors in test output? If a real NameError exception were being generated by the code inside the assert block, we could rely on the test framework to report that exception, right?

Hello. With test/unit and Ruby 1.8.7 (I can be more specific if that matters), wrong's assert { } calls don't show up in the assertion counts. Running the following file

require 'rubygems'
require 'test/unit'
require 'wrong'

class WrongTest < Test::Unit::TestCase
  include Wrong
  def test_something
    puts 'tested something'
    assert { true }
  end
end

Gives me this output:

Loaded suite wrong_test
Started
tested something
.
Finished in 0.000497 seconds.

1 tests, 0 assertions, 0 failures, 0 errors

I'm not too familiar with Test/Unit internals but with a pointer in the right direction I can probably write you a fix for this.

Oh, and thanks for this gem, I'm really loving it so far.

I installed wrong to win an argument (and I won), but I couldn't run it...

$ ruby2.5 test_me.rb 
Traceback (most recent call last):
	11: from test_me.rb:2:in `<main>'
	10: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:39:in `require'
	 9: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:135:in `rescue in require'
	 8: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:135:in `require'
	 7: from /var/lib/gems/2.5.0/gems/wrong-0.7.1/lib/wrong.rb:6:in `<top (required)>'
	 6: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
	 5: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
	 4: from /var/lib/gems/2.5.0/gems/wrong-0.7.1/lib/wrong/helpers.rb:5:in `<top (required)>'
	 3: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
	 2: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
	 1: from /var/lib/gems/2.5.0/gems/wrong-0.7.1/lib/wrong/close_to.rb:1:in `<top (required)>'
/var/lib/gems/2.5.0/gems/wrong-0.7.1/lib/wrong/close_to.rb:12:in `<module:Wrong>': uninitialized constant Wrong::Date (NameError)
Did you mean?  Data

ruby 2.5.5p157 on Raspbian and ruby 2.5.1p57 on Ubuntu both have the same problem.

Hi, I run my tests with warnings enabled, and each test outputs:

[...]/wrong-0.5.4/lib/wrong/assert.rb:23: warning: instance variable @_inside_wrong_assert not initialized

Adding the following just before the offending line solves this:

@_inside_wrong_assert ||= false

Running bundler with a command like: bundle outdated

I am starting to get this ( since June 7th when sexp_processor got upgraded to version 4 ).

Bundler could not find compatible versions for gem "sexp_processor":
In Gemfile:
wrong (>= 0.6.2) ruby depends on
sexp_processor (~> 3.0) ruby

wrong (>= 0.6.2) ruby depends on
  sexp_processor (4.0.0)

I have this spec:

it "should create Foo" do
  expect{
    post :create, foo: {owner_id: 1, bar_id: 1}
  }.to change(Foo, :count)
  expect(assigns(:foo).owner_id).to eq(1)
  expect(assigns(:foo).bar_id).to eq(1)
  expect(response).to redirect_to(root_path)
end

Run with everything but the last line, it succeeds. But with the last line, this happens:

1) FoosController should create group ownership
   Failure/Error: expect(response).to redirect_to(root_path)
   RuntimeError:
     You must pass a block to Wrong's assert and deny methods
   # /Users/john/src/wrong/lib/wrong/assert.rb:31:in `rescue in assert'
   # /Users/john/src/wrong/lib/wrong/assert.rb:27:in `assert'
   # ./spec/controllers/foos_controller_spec.rb:9:in `block (2 levels) in <top (required)>'

It's as if alias_assert :expect is being invoked, but just for that one spec.

I've experimented with different combinations and orderings and determined that the problem only happens when redirect_to is present.

Any ideas?

Hi again.

Using Ruby 1.8.7 and test/unit running this file:

require 'rubygems'
require 'test/unit'
require 'wrong'

class WrongTest < Test::Unit::TestCase
  include Wrong
  def test_something
    assert { false }
  end
end

Gives me this output:

Loaded suite wrong_test
Started
E
Finished in 0.003617 seconds.

  1) Error:
test_something(WrongTest):  
Wrong::Assert::AssertionFailedError: Expected false
    /Users/minciue/.rvm/gems/ree-1.8.7-2011.03/gems/wrong-0.5.0/lib/wrong/assert.rb:68:in `aver'
    /Users/minciue/.rvm/gems/ree-1.8.7-2011.03/gems/wrong-0.5.0/lib/wrong/assert.rb:34:in `assert'
    wrong_test.rb:8:in `test_something'

1 tests, 0 assertions, 0 failures, 1 errors

Thank you.

https://github.com/ranmrdrakono/wrong/blob/master/lib/wrong/assert.rb#L23-L24

This lines cause race conditions. I propose to use thread_variable to identify recursion problems while avoiding multi threading issues

How can Wrong's assert {} be counted as an assertion ?

After having built the gem with the command:

• gem build wrong.gemspec
  I tried to install it with the command:
• gem install wrong-0.6.3.gem
  but I got the following error:
• ERROR: While executing gem ... (Gem::DependencyError)
  Unable to resolve dependencies: wrong requires sexp_processor (>= 4.0); sourcify requires sexp_processor (>= 3.0.5); ParseTree requires sexp_processor (> 3.2.0); ruby2ruby requires sexp_processor (> 4.0); ruby_parser requires sexp_processor (~> 4.1)

The dependencies on sexp_processor don't seem can all be satisfied, as ParseTree dependes on a version which can't satisfy all the others.

My environment is:
Windows 7 64bit, Ruby 1.9.3

In Rails 4 with rspec_rails, my assert method is from minitest, not from wrong.

Here's an app demonstrating the problem: https://github.com/jjb/rails_4_rspec_rails_wrong

Here's the relevant commit: jjb/rails_4_rspec_rails_wrong@c59d8f4

I tried putting require 'wrong/adapters/minitest' above and below the rspec require in spec_helper, it made no difference.

rspec_rails does all these handy matcher delegations, maybe that contributes to the problem?

I didn't try a pure-rspec experiment. Let me know if you are at a loss and I will try that.

I am using rspec with wrong in a rails app. I have the followin in my spec_helper.rb file:

require "wrong/adapters/rspec"
Wrong.config.alias_assert :confirm

However, when I used assert_select, eg:

  assert_select 'tbody > tr', count: 4

I get the error:

RuntimeError: You must pass a block to Wrong's assert and deny methods

The exception is thrown from

~/.rvm/gems/ruby-1.9.3-p125/gems/actionpack-3.2.9/lib/action_dispatch/testing/assertions/selector.rb

on line 297:

assert matches.size >= min, message if min

It seems wrong is taking over Test::Unit's assert function, causing the function to crash. The alias_assert also doesn't help, since it just aliases the method - the assert method is still there.

I am currently using the following as a workaround:

obj = Object.new
class << obj
  include Test::Unit::Assertions
end
Wrong::Assert.send(:define_method, :assert) do |*args, &block|
  obj.assert(*args, &block)
end

It works, but it would be nice if a better solution was available.

require 'wrong'
include Wrong
assert{(1..2) == (1..1)}

produces a NoMethodError instead of the usual description (tested on ruby 2.1 and 1.9.3)

read_here_or_higher doesn't expect its first argument to be an absolute path, which, on Windows, leads to inability to retrieve an assertion's source if it is located in a file other than the program's entry point.

The easiest way to reproduce is to create a file containing the following:

require 'wrong'
include Wrong::Assert
assert{false}

and then require it from irb. On Windows, instead of "Expected false (Wrong::Assert::AssertionFailedError)" you get "[couldn't retrieve source code due to #<Errno::EINVAL: Invalid argument - ./c:/absolute/path/to/your/file.rb>]"

need to detect that we're in rspec, and if so, shrink the virtual terminal width so the lines wrap better