Split expect_with :stdlib into expect_with :test_unit and expect_with :minitest

[cupakromer]

Follow up to #1462.

[cupakromer]

I'm up for tackling this one this week if no one else wants it.

[myronmarston]

I'm up for tackling this one this week if no one else wants it.

All yours :).

[myronmarston]

Thanks for tackling this, @cupakromer. Taking a look now.

BTW, github didn't notify me you had this ready, so in the future feel free to ping us to let us know you've got something ready when you convert an issue to a PR.

[myronmarston]

You can use :test_unit or :minitest on any version of ruby. (The version was just about which was included in the standard library, but both are available as gems that can be installed on all versions of ruby).

[cupakromer]

Sounds good. I'll remove.

[myronmarston]

Solid work, @cupakromer!

[myronmarston]

The other thing this'll need is a deprecation warning in 2.99. Actually, to deprecate this properly I think you have to backport this (but keep :stdlib) so that people can switch from :stdlib to one of the other options in 2.99 when they get the warning, then continue upgrading. Hopefully that backport will be easy...

[cupakromer]

@myronmarston thanks for taking a look. I had a branch up for a bit, but never attached it until last night. It was late when I finished pushing and got busy with things this morning. So you're right on top of it.

[cupakromer]

I'll make a new PR for the backport to 2.99 later this afternoon.

[myronmarston]

Is this just needed to provide the assertions attribute for the test-unit cases that need it? If so, I think it's less hacky/simpler to just copy over this bit of the minitest adapter:

      attr_writer :assertions
      def assertions
        @assertions ||= 0
      end

It shouldn't cause any problems to have that attribute defined even if it's not used. Thoughts?

[cupakromer]

I thought about doing this. I agree that it doesn't necessarily hurt to have it duplicated here too. My reasoning for not taking that route was:

• this isn't coincidental duplication; we're duplicating these lines solely because minitest is being loaded
• we don't always load minitest, so why have the extra API surface area
• if more dependencies are required by minitest in the future we need to make sure to add them in two places; I know I personally would forget to add it to 'test_unit' if that were to happen
• the code in this manner is fairly self documenting, I'd feel odd duplicating the comments about the minitest issue again here
• I considered making a minitest_assertions_hooks module, which I could include in both; though part of me though this was slightly better documenting

With all that having been said. Neither of these modules have specs around them. I probably easily could just use a shared_examples_for "provides minitest hooks" to help add the documentation.

Honestly, I'm on the fence about my approach and figured I'd make sure it passed on all versions and then solicit feedback.

[myronmarston]

Here's an alternate idea (that I'm just tossing out there but don't necessarily recommend): define a subclass of Module that provides the assertions accessor and accepts an argument for what additional assertion module to include:

module RSpec
  module Core
    class AssertionAdapter < Module
      def initialize(assertion_module)
        module_exec do
          include assertion_module

          attr_writer :assertions
          def assertions
            @assertions ||= 0
          end
        end
      end
    end
  end
end

Then the :test_unit option will be translated to RSpec::Core::AssertionAdapter.new(::Test::Unit::Assertions) and the :minitest option will be translated to RSpec::Core::AssertionAdapter.new(::Minitest::Assertions).

I'm on the fence about which solution is best, honestly. This idea is potentially confusing (subclassing Module is pretty non-standard) but it feels like the right kind of abstraction for this -- the adapter is it's own thing, not tied to test_unit or minitest and can receive any assertion module as an argument.

If you feel like switching to this feel free, otherwise I'm fine merging what you have. You clearly thought about this a lot and you're thinking about the right things :).

[myronmarston]

This LGTM. Left a couple comments but they aren't merge blockers. Thanks @cupakromer!

[myronmarston]

One other thing I just remembered...we need a 2.99 deprecation for expect_with :stdlib since it will no longer be supported in 3.0. Would you like me to take care of that or are you on it, @cupakromer?

[cupakromer]

@myronmarston yep, have it open right now in fact. Will make final changes soon then merge this, and should have the 2.99 push in an hour or so.

[JonRowe]

This comment makes no sense, it's also present in the 2.99 deprecation.

[cupakromer]

Which part? There's a difference in the upcase on Test between minitest 4.x and 5.x. Would this be a bit more explicit?

Loading `test/unit/assertions` sometimes also loads a
version of minitest:

- Ruby 1.8 does not load any minitest files

- the test/unit gem does not include any minitest files

- Ruby core 1.9+ test/unit/assertions includes
  `MiniTest::Assertions`. Note the upcasing of 'Test' in
  'MiniTest'. It loads this by requiring 'minitest/unit'.

- If Minitest 5.x is loaded when Ruby core 1.9+ requires
  'minitest/unit', the gem sets 'MiniTest' to an alias of it's
  'Minitest'

Minitest 5.x added new dependencies to 'Minitest::Assertions';
note the lowercasing of 'test' in 'Minitest' now. Only if this
module is loaded do we need to add a shim for these new
dependencies.

[JonRowe]

Ahh the the casing is different, prehaps just amending these two lines to:

# 4.x uses the `MiniTest` constant (note capitalisation) 
# 5.x uses the `Minitest` constant