Define weak/default memoized helpers with `let?` method.

[sleepingkingstudios]

Define weak/default memoized helpers with `let?` method.

[sleepingkingstudios]

@pirj @JonRowe I think I'm going in a different direction here, but I just wanted to say thank you for taking the time to go through this "the RSpec way". RSpec is always the first thing I add to any new project or recommend, not just because the code is rock solid but because the support and the community are always there, and it's deeply appreciated. Cheers!

[pirj]

After a semi-relevant recent discussion in #3076, I have doubts if we would want to add such a feature in the core.

I can only guess why if there’s just one variable, it is not explicitly defined in the calling code, and is set a default value in the shared example group. Would it be used to ease up the test setup for describing a subject dependent on many variables?
Without more specifics, I’d say it would only bury the complexity deeper.
I would be most concerned as a reader of a spec to what values of variables are used in each context.

All kinds of extensions exist, built for various purposes, some very useful for performance like let_it_be.
I would suggest writing an extension and providing sone convincing examples of making code easier to read.

Personally, I would change your example to

RSpec.describe Processor do
  shared_examples 'processes the input' do
    it 'processes the input' do
      expect { subject.process(input, **options) }.not_to raise_error
    end
  end

  let(:input) { 'Greetings, programs!' }
  let(:options) { {} } # default

  include_examples 'processes the input'

  context 'with **non-default** options' do
    let(:options) { { capitalize: true } }

    include_examples 'processes the input'
  end
end

[sleepingkingstudios]

Fair enough, and I apologize for not checking the closed issues for relevance. If it helps understand the context - my end goal is to be able to define portable tests. For example, a transportation gem might define a shared contract for being a valid form of transport, while the race_car, dirigible, and rocket gems that depend on transportation could then pull in the tests and verify that their implementations match. This isn't a hypothetical for me, it's a problem I'm specifically trying to solve for Collection implementations for cuprum-collections. Still, if there's not much interest in tackling this in core at this time I'll just build it into my own testing helper gem.

[pirj]

No worries. I think I understand your use case, and I have some experience with such specs as a user.

I wonder if there could be a single entry to such shared specs, and if it can be optionally overridden by the code using them?

RSpec.shared_examples “processes the input” do
  let(:foo) { :default }
  it { … }
end

RSpec.describe do
  it_behaves_like “processes the input” # with defaults
  it_behaves_like “processes the input” do
    let(:foo) { :override }
  end
end

Would this be of some help? Does it even work as I remember it should?

[sleepingkingstudios]

I think it works that way. It feels inside out relative to how RSpec usually works, though. I think a lot of the trouble I'm having is working around the use cases where shared example groups are kind of like including a module, except when they're not.

What I really want in the end is to be able to share tests between projects/libraries, but I kind of suspect that's going to be considered way out of scope no matter how elegant I think the solution is. I think the intended way to do that in RSpec is creating a shared example group in the top-level scope which adds it to RSpec.world, but feel free to correct me if I'm missing something obvious.

[JonRowe]

Shared examples are a context [e.g they are a class inheriting from the parent] in their own right where as shared contexts are not, this is why there is a slight difference in how inclusion works. You should be able to do what @pirj suggests and have it just work.

e.g. this won't work because the parent class's definition is overridden.

RSpec.shared_examples “processes the input” do
  let(:foo) { :default }
  it { … }
end

RSpec.describe do
  let(:foo) { :override }
  it_behaves_like “processes the input” # with defaults
end

e.g but this should becase its defined in the class

RSpec.shared_examples “processes the input” do
  let(:foo) { :default }
  it { … }
end

RSpec.describe do
  it_behaves_like “processes the input” # with defaults
  it_behaves_like “processes the input” do
    let(:foo) { :override }
  end
end

You can also check in the shared example for the presence of the method before defining the let