Allow to use the matchers with just rspec expectations gem #910

majioa · 2016-03-02T14:37:24Z

Allow to use the matchers for the just rspec expectations, apart the whole

RSpec.

It adds the specific test framework that just includes the specified
libraries directly to RSpec::Matchers.

The addition is covered with an acceptance test.

houndci-bot · 2016-03-02T14:37:27Z

spec/support/acceptance/adds_shoulda_matchers_to_project.rb

@@ -94,7 +94,8 @@ def test_helper_files_for(test_framework, libraries)
      files = []

      if integrates_with_nunit_and_rails?(test_framework, libraries) ||
-        integrates_with_nunit_only?(test_framework)
+        integrates_with_nunit_only?(test_framework) ||


Align the operands of a condition in an if statement spanning multiple lines.

houndci-bot · 2016-03-02T16:30:19Z

lib/shoulda/matchers/integrations/test_frameworks/rspec_expectations.rb

+EOT
+          end
+
+          def include(*modules, **options)


Unused method argument - options. If it's necessary, use _ or _options as an argument name to indicate that it won't be used.

…whole RSpec. * It adds the specific test framework that just includes the specified libraries directly to RSpec::Matchers. The addition is covered with an acceptance test.

TheTeaNerd · 2018-10-20T18:31:05Z

README.md

@@ -197,6 +197,30 @@ describe Person do
 end
 ```

+### RSpec-Expectations
+
+Use this instead of the RSpec ifself in case you just use the specific module gem


I think the English can be improved here, I was a little confused by it. I suggest:

`shoulda-matchers` can be configured to only need the `rspec-expectations` gem instead of the full RSpec suite. Firstly, include `shoulda-matchers` in your Gemfile:

...it was much harder than I expected to find a good starting point here! Could you perhaps give a one-liner for why you want to use only RSpec-Expectations and not the full suite? Speed? Load-time? Fewer dependencies?

usage with only cucumber )

TheTeaNerd · 2018-10-20T18:32:47Z

README.md

+
+    Shoulda::Matchers.configure do |config|
+      config.integrate do |with|
+        with.test_framework :rspec_exp


I think it would be more expressive / more obvious to use rspec_expectations instead of rspec_exp.

could the exp statement be understood some else than expectations in context of rspec?

Going along with the use case, instead of with.test_framework :rspec_exp, this would be with.test_framework :cucumber.

because the cucumber is the only explicit example, and may be someone will want to use expectations' syntax without cucumber, but on the same way, for example on test-unit replacinf assert syntax.

TheTeaNerd · 2018-10-20T18:33:09Z

README.md

+
+Then, configure the gem to integrate with RSpec specifying the test framework as `:rspec_exp`:
+
+    Shoulda::Matchers.configure do |config|


Missing a code block here?

here is indent 4 step

TheTeaNerd · 2018-10-20T18:33:29Z

README.md

+      end
+    end
+
+Now you can use matchers in your tests as for RSpec part.


I think this line is redundant and could be removed for simplicity.

TheTeaNerd · 2018-10-20T18:34:42Z

lib/shoulda/matchers/integrations/test_frameworks/rspec_expectations.rb

+
+          def validate!
+            return if defined? RSpec::Matchers
+            raise TestFrameworkNotFound, <<-EOT


Unless there's a need to explicitly support Ruby < 2.3, this would be nicer with a 'squiggly heredoc': https://infinum.co/the-capsized-eight/multiline-strings-ruby-2-3-0-the-squiggly-heredoc

I'm fine with this -- this makes it easier to wrap the message at 80 characters.

mcmire

Hey @majioa. Sorry that we haven't responded to this yet. 😬 The bad news is that we're in a code freeze right now, so we can't merge this in quite yet, but the good news is that we almost have 4.0.0 out, so we will start revisiting some of these older PRs once we have that completed.

That said, I took some time to check over your PR, and I had a thought. I wonder if it would make more sense to reframe this as integrating less with rspec-expectations and more with Cucumber. I can't imagine anyone else would want to use shoulda-matchers just with rspec-expectations, unless they were using it with Cucumber. Certainly there are not many people who would want to even use shoulda-matchers apart from Minitest or RSpec, but in making this integration about Cucumber, I feel like it would fall logically alongside what is already there and would be more understandable to people who are scrolling through the README for the first time. Plus -- and perhaps more importantly -- I feel like it would help us as maintainers understand why this code is here and what purpose it serves. What do you think about this? I added some comments below to point out potential changes.

I had another thought while writing the above. I have been under the understanding that you use Cucumber to write unit tests. However, the integration test you wrote has me wondering if perhaps that's not what you're doing -- in which case, everything I wrote in this PR wouldn't apply. Can you enlighten me?

mcmire · 2018-10-20T21:18:20Z

README.md

@@ -197,6 +197,30 @@ describe Person do
 end
 ```

+### RSpec-Expectations


This would be renamed to "Cucumber", and this whole section would talk about that instead of mentioning rspec-expectations.

mcmire · 2018-10-20T21:19:22Z

README.md

+
+    Shoulda::Matchers.configure do |config|
+      config.integrate do |with|
+        with.test_framework :rspec_exp


Going along with the use case, instead of with.test_framework :rspec_exp, this would be with.test_framework :cucumber.

mcmire · 2018-10-20T21:26:10Z

lib/shoulda/matchers/integrations/test_frameworks/rspec_expectations.rb

+    module Integrations
+      module TestFrameworks
+        # @private
+        class RspecExpectations


Instead of RspecExpectations, this would be Cucumber, and everything in this file would talk about that rather than rspec-expectations.

mcmire · 2018-10-20T21:27:47Z

lib/shoulda/matchers/integrations/test_frameworks/rspec_expectations.rb

+
+          def validate!
+            return if defined? RSpec::Matchers
+            raise TestFrameworkNotFound, <<-EOT


I'm fine with this -- this makes it easier to wrap the message at 80 characters.

mcmire · 2018-10-20T21:29:31Z

lib/shoulda/matchers/integrations/test_frameworks/rspec_expectations.rb

+          end
+
+          def include(*modules, **_options)
+            RSpec::Matchers.send(:include, *modules)


So now, instead of including modules into RSpec::Matchers (which requires understanding that RSpec::Matchers is itself mixed into Object), this could be World(*modules) (which is a public API).

mcmire · 2018-10-20T21:30:24Z

spec/acceptance/rspec_expectation_test_framework_integration_spec.rb

@@ -0,0 +1,59 @@
+require 'acceptance_spec_helper'
+
+describe 'shoulda-matchers integrates libs for rspec-expectations framework' do


This file would be renamed/reframed to represent Cucumber and would set up a Cucumber project.

mcmire · 2018-10-20T21:33:48Z

spec/support/acceptance/adds_shoulda_matchers_to_project.rb

@@ -118,6 +119,10 @@ def integrates_with_rspec?(test_framework)
      test_framework == :rspec
    end

+    def integrates_with_rspec_expectations?(test_framework)


This would be integrates_with_cucumber?. You'd have to modify test_helper_files_for to do:

if integrates_with_cucumber?(test_framework) files << 'features/support/env.rb' end

mcmire · 2018-10-20T21:52:41Z

spec/acceptance/rspec_expectation_test_framework_integration_spec.rb

+      end
+    FILE
+
+    append_rake_task 'rspec_exp', 'environment', <<-CODE


Instead of appending to a rake task like this, I would actually write this to a file. In the case of Cucumber this could be features/cucumber_integration.feature or whatever you want to call it. Unless that's not how you actually write your tests? I'm a bit confused here. Please enlighten me :)

@mcmire If we suppose that the case is limited by cucumber case that should be true, but because the cucumber is the only explicit example, and may be someone will want to use expectations' syntax without cucumber, but on the same way, for example on test-unit replacing assert syntax. That is why I just used the common case called rspec-exp/rspec-expectations to describe the feature. Well it may be not so correct naming convention for the case, but cucumber is also not a proper naming.

majioa · 2018-10-22T10:57:02Z

@mcmire If we suppose that the case is limited by cucumber case that should be true, but because the cucumber is the only explicit example, and may be someone will want to use expectations' syntax without cucumber, but on the same way, for example on test-unit replacing assert syntax. That is why I just used the common case called rspec-exp/rspec-expectations to describe the feature. Well it may be not so correct naming convention for the case, but cucumber is also not a proper naming. May be it should have name expectation-commons?

mcmire · 2018-10-22T14:41:55Z

@majioa My sense is that making a more generic adapter would be premature abstraction. If someone else comes forward later and says that they want to use RSpec syntax with Test::Unit down the line, then I would take that into consideration, but you're literally the only person who's proposed anything like this, and I don't want to confuse the 99% of the userbase who is perfectly happy using shoulda-matchers with the full RSpec experience.

That said, can you provide an example of the type of test that you write? I'm not still clear on how you plan on using this.

mcmire · 2020-05-06T07:35:27Z

Hey folks. In an effort to lighten our load as maintainers and be able to serve you better in the future, the shoulda-matchers team is working on cleaning out the cobwebs in this repo by pruning the backlog. As there are few of us, there are a lot of items that will simply never earn our attention in a reasonable time frame, and rather than giving you an empty promise, we think it makes more sense to focus on more recent issues. That means, unfortunately, that we must close this PR.

Don't take this the wrong way: our aim is not to diminish the effort people have made or dismiss problems that have been raised. If you feel that we should reopen this PR, then please let us know so that we can reprioritize it. Thanks!

majioa · 2020-05-06T09:08:54Z

@mcmire https://github.com/majioa/shoulda-matchers-cucumber

mcmire · 2020-05-06T19:30:49Z

Oh very nice! I've added your extension to the README: https://github.com/thoughtbot/shoulda-matchers#extensions

houndci-bot reviewed Mar 2, 2016
View reviewed changes

majioa mentioned this pull request Mar 2, 2016

Allow the use of matchers with just rspec expectations gem #737

Closed

houndci-bot reviewed Mar 2, 2016
View reviewed changes

Allow the use of matchers for the just rspec expectations, apart the …

e8c7db1

…whole RSpec. * It adds the specific test framework that just includes the specified libraries directly to RSpec::Matchers. The addition is covered with an acceptance test.

mcmire added the 🏃‍♀️PR: In Progress label Jun 14, 2016

mcmire added ⏱ PR: In Queue for Review and removed 🏃‍♀️PR: In Progress labels Jul 12, 2016

TheTeaNerd reviewed Oct 20, 2018

View reviewed changes

mcmire reviewed Oct 20, 2018

View reviewed changes

mcmire added 🏃‍♀️PR: In Progress and removed ⏱ PR: In Queue for Review labels Oct 20, 2018

mcmire closed this May 6, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow to use the matchers with just rspec expectations gem #910

Allow to use the matchers with just rspec expectations gem #910

majioa commented Mar 2, 2016

houndci-bot Mar 2, 2016

houndci-bot Mar 2, 2016

TheTeaNerd Oct 20, 2018 •

edited

majioa Oct 20, 2018

TheTeaNerd Oct 20, 2018

majioa Oct 20, 2018

mcmire Oct 20, 2018

majioa Oct 22, 2018

majioa Oct 22, 2018

majioa Oct 22, 2018

majioa Oct 22, 2018

TheTeaNerd Oct 20, 2018

majioa Oct 20, 2018

TheTeaNerd Oct 20, 2018

majioa Oct 20, 2018

TheTeaNerd Oct 20, 2018

majioa Oct 20, 2018

mcmire Oct 20, 2018

mcmire left a comment

mcmire Oct 20, 2018

mcmire Oct 20, 2018

mcmire Oct 20, 2018

mcmire Oct 20, 2018

mcmire Oct 20, 2018

mcmire Oct 20, 2018

mcmire Oct 20, 2018

mcmire Oct 20, 2018

majioa Oct 22, 2018

majioa commented Oct 22, 2018

mcmire commented Oct 22, 2018

mcmire commented May 6, 2020

majioa commented May 6, 2020

mcmire commented May 6, 2020


		Then, configure the gem to integrate with RSpec specifying the test framework as `:rspec_exp`:

		Shoulda::Matchers.configure do \|config\|

		@@ -0,0 +1,59 @@
		require 'acceptance_spec_helper'

		describe 'shoulda-matchers integrates libs for rspec-expectations framework' do

Allow to use the matchers with just rspec expectations gem #910

Allow to use the matchers with just rspec expectations gem #910

Conversation

majioa commented Mar 2, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TheTeaNerd Oct 20, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mcmire left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

majioa commented Oct 22, 2018

mcmire commented Oct 22, 2018

mcmire commented May 6, 2020

majioa commented May 6, 2020

mcmire commented May 6, 2020

TheTeaNerd Oct 20, 2018 •

edited