Fix for using Minitest (~> v5.0) appropriately

[cookrn]

Hello,

I ran into the issue discussed in #489 while building a gem today and implemented a quick fix. This is here simply to demonstrate a way around the issue and propose a solution. I honestly find it a bit brittle, but am curious about what the feedback will be. Should specific test framework support be fully separated from cucumber?

Also, I started documenting additional tests based on framework in the mentioned feature file, but was unable to get any of my attempts to run correctly. Any assistance on this front would be greatly appreciated as well.

Consider this a work in progress.

[cookrn]

Random note: the array of proc mappings could be cleaned up into a constant mapping frameworks to a set of procs containing the require string and appropriate constant. If this approach is acceptable, that may make the code more clear.

[cookrn]

Lastly, to use Minitest::Assertions properly, see the below example env.rb

# FILE: features/support/env.rb
require 'applicator' # my gem; irrelevant in this context
require 'minitest'

World do
  Minitest::Test.new 'Cucumber Feature'
end

[mattwynne]

Thanks for looking into this @cookrn. @tooky I think we should move this behaviour into http://github.com/cucumber/multi_test. WDYT?

[cookrn]

This is new territory for me and I apologize in advance if this has already been discussed in detail elsewhere.

The idea of separating out anything specific to an assertion/specification framework seems like the right move and what you all had already decided on. Right on! 😄

Just to be clear, I think the following is what we're discussing:

• using any arbitrary test framework's assertions in Cucumber steps
• how to actually integrate a framework into a Cucumber World
• how to nuke a framework's auto-runner
• how to decide which framework a user might want if they didn't specify one

Placing conditions for every possible framework into a single gem i.e. https://github.com/cucumber/multi_test may make things challenging though. If I go and develop my own new specification framework and want to support Cucumber, would I need a PR accepted and a new release cut on multi_test? Can't the community provide integrations as gems for whatever framework they desire if Cucumber gave them a public API/hook and documentation for how to build one? Thus, to use any assertion/specification library, you'd have to specify one in a Gemfile (or equivalent) and require it. Is it acceptable for there to be no default assertion library?

[tooky]

@cookrn I've released a new version of cucumber/multi_test that integrates these changes - thanks for your help.

It's responsibility is to select the most appropriate assertions library from the common ruby assertion libraries. This doesn't preclude anyone from using other assertion libraries.

Cucumber at this point has automatically selected the best assertion library, and we need to continue to support that for 1.3.x.

We are trying to keep 2.0 as close to backwards compatible with 1.3 as we can - as we are pulling out the core it's likely that we will break things that we don't realise, so we don't want to introduce other breaking changes.

I think there's a lot to be said for creating some integration points so we could have cucumber-rspec or cucumber-minitest gems, and anyone producing a new assertions library could add their own, but I don't think we'll look at that before 3.0.

[cookrn]

@tooky I appreciate your feedback & thoughts. Keep up the great work!

[mattwynne]

Thanks @tooky!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.