Keep rspec-given alive! #52
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As of a recent [commit](https://github.com/rspec/rspec-expectations/blame/79582c2c160ac7b3a58d3d128012b022c63d6174/lib/rspec/matchers/built_in/raise_error.rb#L38) to rspec-expectations, Rspec::Matchers::BuiltIn::RaiseError strictly requires a Proc rather than something that quacks like one.
Reverts half of be0b142 @ronen: it looks like what happened here is that does_not_match#super will pass whatever it is given into `matches?` and as a result, the matcher was never ever being passed an actual ::Given::Failure. This caused all of the (already red) negative cases to remain red even after the patch.
Jim had published 2.12.0 as the lowest supported RSpec version, but under that version, several important tests fail. I've updated the lowest supported version to 2.14.0 (the earliest version at which all tests pass)
Rspec3 support
This change is very basic: if ActiveSupport::TestCase is defined, then require minitest-given under an artificial circumstance in which Minitest::Spec is aliased to ActiveSupport::TestCase (so that TestCase absorbs all of the monkey-patching normally applied to Minitest::Spec). This will be a breaking change to anyone currently using Minitest::Spec directly from a test suite that loads Rails, but it's not clear to me that this is a common (if possible?) use case. If that use case matters, it may be necessary to force-load all the files again after un-aliasing the Minitest::Spec constant. lib/minitest-given was changed so that Bundler's auto-require would pick up the same intelligence that `require 'minitest/given'` will now have.
Support minitest-given use in Rails tests
The build will fail for older versions of RSpec 2+, but the lib will continue to support them
`value` is defined by Minitest::Spec and will error when a `let` is created with that name
I hate effectively branching in tests, but this is necessary to make the build pass under RSpec 2.x, as I forgot all the same tests are run against both
Fixes the build
…ls so it works for both at the same time.
that Given works with ActiveSupport::TestCase. Keeping blocks to one line despite length.
It looks like Jim's idea with `_Gvn_before` was to have each framework quack with its own implementation. This commit keeps the Minitest before hacks on its side of the fence (and the RSpec before extension that simply delegates to RSpec before remains in place).
Make rspec-given work for both TestCase and Minitest::Spec together.
Updated code that compares the version of JRUBY to '1.7.5' to determine if natural assertions are supported. Fixes #2.
warning: assigned but unused variable - ex
fix warning
Add natural assertions support for JRuby 1.7.10 and higher
RSpec changed how it detects source lines to print in rspec/rspec-core#2088, which necessitates us configuring `project_source_dirs` for our specs. (This should not affect end-users). In addition, we now print multi-line code snippets as of rspec/rspec-core#2083. Multiline snippets are not printed on the same line as `Failure/Error:` so our regex has to be updated to accommodate a line break.
Having the if-else branch wrap the entire describe confused me, because I couldn't tell whether the metadata support we offer differs substantially between RSpec 2 & 3 (it conflated the fact that RSpec 3 added default-true metadata, which 2 lacks with the fact the `example` DSL was removed from RSpec 3) I decided to make the default-to-true metadata example more explicit, as well, including a slightly more rugged rspec_3_or_later? helper available to the rest of the unit test sutie.
Bump travis to test against the latest rubby
…older versions of JRuby This closes #15.
Because this is a publicly available method (even though zero people likely need/know it exists), I'm going to do a minor version bump over it.
Since the messages you get on non-Ripper Rubies are borderline worthless I'm not comfortable saying that natural assertions are supported per se, just agree that it's no longer enough for rspec-given to blow up. This also lets us use a meaningfully named constant we own to branch around the ripper/sorcerer stuff instead of doing defined? checks on ripper/sorcerer. Additionally, having two LoadErrors was duplicative and would result in two very similar warnings hitting a person's console.
This reverts commit 35d2f82. Because we're publishing multiple gems, using rspec-given from the git repo does not quite work correctly or make sense.
`Then { }` shouldn't fail normally (and doesn't), but the way we
ascertain that is by verifying via ripper that the statement is a
:void_stmt.
I don't want to get into the business of manually parsing Ruby with
regex to guess whether I'm looking at a void assertion statement, so
I'm just going to add to the warning that these will also fail without
Ripper.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Because Jim is no longer with us, this pull request will sadly never be merged. It will stand as a sign post to anyone looking for updates on rspec-given. 💚
Work on rspec-given continues at https://github.com/rspec-given/rspec-given and adds support for RSpec 3, among other ongoing fixes. If you have an issue with rspec-given, we'd ask you to open it on that repo.
We've been granted push access to the
given_core,rspec-given, andminitest-givenruby gems, and will continue to publish updates and fixes.