Split `expect_with :stdlib` into `expect_with :test_unit` and `expect_with :minitest` #1466

Merged
merged 8 commits into from Apr 24, 2014

Conversation

Projects
None yet
3 participants
@cupakromer
Member

cupakromer commented Apr 18, 2014

Follow up to #1462.

@cupakromer

This comment has been minimized.

Show comment
Hide comment
@cupakromer

cupakromer Mar 31, 2014

Member

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

Member

cupakromer commented Mar 31, 2014

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

@myronmarston

This comment has been minimized.

Show comment
Hide comment
@myronmarston

myronmarston Mar 31, 2014

Member

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

All yours :).

Member

myronmarston commented Mar 31, 2014

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

All yours :).

@myronmarston

This comment has been minimized.

Show comment
Hide comment
@myronmarston

myronmarston Apr 18, 2014

Member

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.

Member

myronmarston commented Apr 18, 2014

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.

- * minitest assertions in ruby 1.9
- * rspec/expectations _and_ stlib assertions
+ * test/unit assertions in ruby 1.8
+ * minitest assertions in ruby 1.9

This comment has been minimized.

@myronmarston

myronmarston Apr 18, 2014

Member

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).

@myronmarston

myronmarston Apr 18, 2014

Member

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).

This comment has been minimized.

@cupakromer

cupakromer Apr 18, 2014

Member

Sounds good. I'll remove.

@cupakromer

cupakromer Apr 18, 2014

Member

Sounds good. I'll remove.

@@ -81,20 +80,78 @@ Feature: configure expectation framework
When I run `rspec example_spec.rb`
Then the output should contain "2 examples, 2 failures"
- Scenario: Configure rspec/expecations AND test/unit assertions
+ Scenario: Configure minitest assertions (passing examples)

This comment has been minimized.

@myronmarston

myronmarston Apr 18, 2014

Member

Do you think that creating seperate scenarios for passing vs failing examples has documentation value? I can see a bit of a benefit for test organization but this makes the docs more verbose (with no obvious doc value) so I think I'd prefer not to see them split.

@myronmarston

myronmarston Apr 18, 2014

Member

Do you think that creating seperate scenarios for passing vs failing examples has documentation value? I can see a bit of a benefit for test organization but this makes the docs more verbose (with no obvious doc value) so I think I'd prefer not to see them split.

This comment has been minimized.

@cupakromer

cupakromer Apr 18, 2014

Member

When I started this, I had no idea what the differences were between test/unit and minitest. I wanted a way to confirm that I had included the proper libs. After some research I found that a few of the test/unit APIs did not work with minitest and vice versa. I used those here for the acceptance features.

I can try to flip the :test_unit and minitest inclusions locally to ensure they fail properly. As you pointed out in another comment, test/unit seems to be a thin shim over minitest now. Thus this may not be necessary. If so, I'm happy to remove and shorten the docs.

@cupakromer

cupakromer Apr 18, 2014

Member

When I started this, I had no idea what the differences were between test/unit and minitest. I wanted a way to confirm that I had included the proper libs. After some research I found that a few of the test/unit APIs did not work with minitest and vice versa. I used those here for the acceptance features.

I can try to flip the :test_unit and minitest inclusions locally to ensure they fail properly. As you pointed out in another comment, test/unit seems to be a thin shim over minitest now. Thus this may not be necessary. If so, I'm happy to remove and shorten the docs.

This comment has been minimized.

@myronmarston

myronmarston Apr 18, 2014

Member

As you pointed out in another comment, test/unit seems to be a thin shim over minitest now.

Well, that depends on if we're talking about stdlib test/unit or the test-unit gem, and also what version of ruby if we're talking about stdlib test/unit. Starting with ruby 1.9, test/unit in the stdlib is a shim over minitest. On 1.8 it's not, and there's also a test/unit gem that has continued to be developed that works on ruby 1.9+ that has no relation to minitest.

@myronmarston

myronmarston Apr 18, 2014

Member

As you pointed out in another comment, test/unit seems to be a thin shim over minitest now.

Well, that depends on if we're talking about stdlib test/unit or the test-unit gem, and also what version of ruby if we're talking about stdlib test/unit. Starting with ruby 1.9, test/unit in the stdlib is a shim over minitest. On 1.8 it's not, and there's also a test/unit gem that has continued to be developed that works on ruby 1.9+ that has no relation to minitest.

This comment has been minimized.

@cupakromer

cupakromer Apr 18, 2014

Member

Hmm. This is probably a large source of my confusion. I'll see if I can properly parse this out.

@cupakromer

cupakromer Apr 18, 2014

Member

Hmm. This is probably a large source of my confusion. I'll see if I can properly parse this out.

This comment has been minimized.

@myronmarston

myronmarston Apr 18, 2014

Member

Yeah, it's confusing. I don't think we need to test all these combinations or do anything to make sure we use stdlib vs gem versions; we should just require whatever version is available.

@myronmarston

myronmarston Apr 18, 2014

Member

Yeah, it's confusing. I don't think we need to test all these combinations or do anything to make sure we use stdlib vs gem versions; we should just require whatever version is available.

This comment has been minimized.

@cupakromer

cupakromer Apr 20, 2014

Member

@myronmarston I'm going to leave these cukes in. I flipped the :test_unit passing example to use :minitest and it fails with: undefined method 'assert_not_equal'

AFAIK these are the only tests which verify that test/unit specific features are loaded properly.

@cupakromer

cupakromer Apr 20, 2014

Member

@myronmarston I'm going to leave these cukes in. I flipped the :test_unit passing example to use :minitest and it fails with: undefined method 'assert_not_equal'

AFAIK these are the only tests which verify that test/unit specific features are loaded properly.

This comment has been minimized.

@myronmarston

myronmarston Apr 21, 2014

Member

I think it's good to have separate scenarios for the different possibilities of expect_with, but I still think that for a given possibility (e.g. :minitest) it's overly verbose and (not valuable for documentation) to have it split into one scenario for failing examples and one for passing examples. This isn't a merge blocker, but does it cause a problem to combine the failing vs passing scenarios for a particular expect_with option into one scenario?

@myronmarston

myronmarston Apr 21, 2014

Member

I think it's good to have separate scenarios for the different possibilities of expect_with, but I still think that for a given possibility (e.g. :minitest) it's overly verbose and (not valuable for documentation) to have it split into one scenario for failing examples and one for passing examples. This isn't a merge blocker, but does it cause a problem to combine the failing vs passing scenarios for a particular expect_with option into one scenario?

This comment has been minimized.

@cupakromer

cupakromer Apr 21, 2014

Member

Sure, I could merge them together. I was just following the pre-existing conventions. I think it probably helps to prevent incorrectly passing specs when they are separate.

Though, right now I'm not sure I can see a case where a passing example would fail and a failing example would pass, thus keeping the Then the output should contain "3 examples, 1 failures" incorrectly passing. I can make the adjustment.

@cupakromer

cupakromer Apr 21, 2014

Member

Sure, I could merge them together. I was just following the pre-existing conventions. I think it probably helps to prevent incorrectly passing specs when they are separate.

Though, right now I'm not sure I can see a case where a passing example would fail and a failing example would pass, thus keeping the Then the output should contain "3 examples, 1 failures" incorrectly passing. I can make the adjustment.

lib/rspec/core/configuration.rb
# config.expect_with OtherExpectationFramework
#
- # RSpec will translate `:rspec` and `:stdlib` into the appropriate
+ # RSpec will translate `:rspec` and `:min` into the appropriate

This comment has been minimized.

@myronmarston

myronmarston Apr 18, 2014

Member

This should be:

RSpec will translate `:rspec`, `:minitest` and `:test_unit` into the appropriate modules.
@myronmarston

myronmarston Apr 18, 2014

Member

This should be:

RSpec will translate `:rspec`, `:minitest` and `:test_unit` into the appropriate modules.

This comment has been minimized.

@cupakromer

cupakromer Apr 18, 2014

Member

Great thanks, totally overlooked it.

@cupakromer

cupakromer Apr 18, 2014

Member

Great thanks, totally overlooked it.

- # `frameworks` can be `:rspec`, `:stdlib`, a custom module, or any
- # combination thereof:
+ # `frameworks` can be `:rspec`, `:test_unit`, `:minitest`, a custom
+ # module, or any combination thereof:

This comment has been minimized.

@myronmarston

myronmarston Apr 18, 2014

Member

Re: "any combination thereof"....can :test_unit and :minitest be used together? There might be weirdness with that combination (given their relationship). I don't think it's useful to use both but if we're going to state you can use any combination it would be good to validate that. Maybe add a scenario to the cuke that uses both?

@myronmarston

myronmarston Apr 18, 2014

Member

Re: "any combination thereof"....can :test_unit and :minitest be used together? There might be weirdness with that combination (given their relationship). I don't think it's useful to use both but if we're going to state you can use any combination it would be good to validate that. Maybe add a scenario to the cuke that uses both?

This comment has been minimized.

@cupakromer

cupakromer Apr 18, 2014

Member

Sounds good.

@cupakromer

cupakromer Apr 18, 2014

Member

Sounds good.

This comment has been minimized.

@cupakromer

cupakromer Apr 20, 2014

Member

I don't foresee any problems with allowing both. When I was testing the cukes for specific syntaxes, I found that requiring :test_unit loads minitest anyways. I confirmed this in Ruby: https://github.com/ruby/ruby/blob/3603063e4385c45db103d979311f689e9146383e/lib/test/unit/assertions.rb#L7

I'll add a cuke showing they work together.

@cupakromer

cupakromer Apr 20, 2014

Member

I don't foresee any problems with allowing both. When I was testing the cukes for specific syntaxes, I found that requiring :test_unit loads minitest anyways. I confirmed this in Ruby: https://github.com/ruby/ruby/blob/3603063e4385c45db103d979311f689e9146383e/lib/test/unit/assertions.rb#L7

I'll add a cuke showing they work together.

lib/rspec/core/configuration.rb
+ ::Test::Unit::Assertions
+ when :minitest
+ begin
+ gem 'minitest'

This comment has been minimized.

@myronmarston

myronmarston Apr 18, 2014

Member

Using rubygems APIs is a code smell, IMO, because it prevents people from controlling their environment in how they wish (e.g. through the use of --disable-gems). See this for example:

http://tomayko.com/writings/require-rubygems-antipattern

Why is this line needed?

@myronmarston

myronmarston Apr 18, 2014

Member

Using rubygems APIs is a code smell, IMO, because it prevents people from controlling their environment in how they wish (e.g. through the use of --disable-gems). See this for example:

http://tomayko.com/writings/require-rubygems-antipattern

Why is this line needed?

This comment has been minimized.

@cupakromer

cupakromer Apr 18, 2014

Member

Honestly, I cargo-culted this from: https://github.com/ruby/ruby/blob/3603063e4385c45db103d979311f689e9146383e/lib/minitest/autorun.rb#L9-L10

I was going to ping you about it today.

This comment has been minimized.

@cupakromer

cupakromer Apr 20, 2014

Member

@myronmarston any additional thoughts on this?

@cupakromer

cupakromer Apr 20, 2014

Member

@myronmarston any additional thoughts on this?

- module StdlibAssertionsAdapter
- include ::Test::Unit::Assertions
+ module MinitestAssertionsAdapter
+ include ::Minitest::Assertions

This comment has been minimized.

@myronmarston

myronmarston Apr 18, 2014

Member

The build is failing because T::U in the stdlib in 1.9+ is a small shim over minitest (although there's also a seperate T::U gem that has no reliance on minitest) and as we've seen minitest requires the assertions attribute. I think you need this assertions attribute for :test_unit as well.

@myronmarston

myronmarston Apr 18, 2014

Member

The build is failing because T::U in the stdlib in 1.9+ is a small shim over minitest (although there's also a seperate T::U gem that has no reliance on minitest) and as we've seen minitest requires the assertions attribute. I think you need this assertions attribute for :test_unit as well.

This comment has been minimized.

@cupakromer

cupakromer Apr 18, 2014

Member

Thanks, this was thoroughly confusing me. I was going to ping you directly about it today. I'll add the shim in here too.

@cupakromer

cupakromer Apr 18, 2014

Member

Thanks, this was thoroughly confusing me. I was going to ping you directly about it today. I'll add the shim in here too.

@myronmarston

This comment has been minimized.

Show comment
Hide comment
@myronmarston

myronmarston Apr 18, 2014

Member

Solid work, @cupakromer!

Member

myronmarston commented Apr 18, 2014

Solid work, @cupakromer!

@myronmarston

This comment has been minimized.

Show comment
Hide comment
@myronmarston

myronmarston Apr 18, 2014

Member

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...

Member

myronmarston commented Apr 18, 2014

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

This comment has been minimized.

Show comment
Hide comment
@cupakromer

cupakromer Apr 18, 2014

Member

@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.

Member

cupakromer commented Apr 18, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@cupakromer

cupakromer Apr 18, 2014

Member

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

Member

cupakromer commented Apr 18, 2014

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

+ end
+ rescue NameError => _ignored
+ # No-op. Minitest::Assertions isn't loaded
+ end

This comment has been minimized.

@myronmarston

myronmarston Apr 21, 2014

Member

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?

@myronmarston

myronmarston Apr 21, 2014

Member

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?

This comment has been minimized.

@cupakromer

cupakromer Apr 21, 2014

Member

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.

@cupakromer

cupakromer Apr 21, 2014

Member

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.

This comment has been minimized.

@myronmarston

myronmarston Apr 21, 2014

Member

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

myronmarston Apr 21, 2014

Member

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 comment has been minimized.

Show comment
Hide comment
@myronmarston

myronmarston Apr 21, 2014

Member

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

Member

myronmarston commented Apr 21, 2014

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

@myronmarston

This comment has been minimized.

Show comment
Hide comment
@myronmarston

myronmarston Apr 24, 2014

Member

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?

Member

myronmarston commented Apr 24, 2014

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

This comment has been minimized.

Show comment
Hide comment
@cupakromer

cupakromer Apr 24, 2014

Member

@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.

Member

cupakromer commented Apr 24, 2014

@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.

cupakromer added some commits Apr 10, 2014

Restrict minitest to 5.x.
We're not sure yet what minitest 6.x will entail. So we're locking the
gem to a 5.x version.
Include feature spec on desired behavior.
Mark feature as `@wip` so it doesn't fail the build while the feature is
being implemented.
Replace `stdlib` with `minitest` & `test_unit`.
- Remove support for the `stdlib` expectation framework
- Include `test_unit`
- Include `minitest`
- In specs treat previous `stdlib` as `minitest`
- Attempt to require the 'minitest' gem
  - Supports minitest with Ruby 1.8.7
  - Supports minitest 5.x which is not part of stdlib
Handle test/unit loading minitest in some cases.
The whole minitest and test/unit loading is a bit complex. It depends
greatly on which Ruby version is being used, and if either the
'test_unit' or 'minitest' gems are available.

The newer Ruby versions (1.9+) use test/unit as a light shim around
minitest. Due to this, they load minitest when test/unit is loaded. This
means we should add the new `assertions` accessors when `:test_unit` is
specified.

However, if either Ruby 1.8 is used or the 'test_unit' gem was loaded,
'minitest' will not be loaded. In these situations we should not be
adding the accessor.
Add support for the minitest + test/unit combos.
RSpec 3.x does not provide explicit support for Minitest 4.x. However,
due to differences in `require` paths, we do provide a fallback option
in the case it is used. We are not in the business of dictating which
versions our users should or should not use, nor on how they setup their
load paths (i.e. bundler or other methods).

There are a lot of subtle issues with the different combinations of
versions of Ruby + test/unit + minitest. These can cause load and name
errors.

- Update the features to specifically check for our desired assertion
  errors; instead of allowing failures due to `NameError` or `LoadError`
- Update the test/unit and minitest adapters to include fallback logic
  when different combinations occur

cupakromer added a commit that referenced this pull request Apr 24, 2014

Merge pull request #1466 from rspec/split-expect_with-stdlib
Split `expect_with :stdlib` into `expect_with :test_unit` and `expect_with :minitest`

@cupakromer cupakromer merged commit 892c66a into master Apr 24, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details

@myronmarston myronmarston deleted the split-expect_with-stdlib branch Apr 24, 2014

+ # RUBY_VERSION we need to check ancestors.
+ begin
+ # MiniTest is 4.x
+ # Minitest is 5.x

This comment has been minimized.

@JonRowe

JonRowe Apr 25, 2014

Member

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

@JonRowe

JonRowe Apr 25, 2014

Member

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

This comment has been minimized.

@cupakromer

cupakromer Apr 25, 2014

Member

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.
@cupakromer

cupakromer Apr 25, 2014

Member

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.

This comment has been minimized.

@JonRowe

JonRowe Apr 25, 2014

Member

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
@JonRowe

JonRowe Apr 25, 2014

Member

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
@@ -41,7 +41,7 @@ Gem::Specification.new do |s|
s.add_development_dependency "rake", "~> 10.0.0"
s.add_development_dependency "cucumber", "~> 1.3"
- s.add_development_dependency "minitest", "~> 5"
+ s.add_development_dependency "minitest", "~> 5.3"

This comment has been minimized.

@JonRowe

JonRowe Apr 25, 2014

Member

We've no way of testing this with Minitest 4 right?

@JonRowe

JonRowe Apr 25, 2014

Member

We've no way of testing this with Minitest 4 right?

This comment has been minimized.

@myronmarston

myronmarston Apr 25, 2014

Member

We could use an alternate gemfile or install it and put it on the load path ourselves. That said, Minitest 4 is legacy at this point. We don't need to explicitly not support it through an error or anything like that, but my position is that we shouldn't put any effort into minitest 4 support and tell people it's not officially supported (at least, not with expect_with :minitest....users can still do expect_with MiniTest::Assertions themselves). If we supported it we'd have to support it until RSpec 4 and I don't want to put that burden on us.

@myronmarston

myronmarston Apr 25, 2014

Member

We could use an alternate gemfile or install it and put it on the load path ourselves. That said, Minitest 4 is legacy at this point. We don't need to explicitly not support it through an error or anything like that, but my position is that we shouldn't put any effort into minitest 4 support and tell people it's not officially supported (at least, not with expect_with :minitest....users can still do expect_with MiniTest::Assertions themselves). If we supported it we'd have to support it until RSpec 4 and I don't want to put that burden on us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment