Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Be less strict when using #hash_including with defaults #674

Conversation

denisdefreyne
Copy link
Contributor

This PR introduces #hash_with_defaults_including, which is similar to RSpec’s built-in #hash_including, but does not require the keys of expected to be present in actual -- what matters is that for all keys in expected, the value in actual and expected is the same.

hash = Hash.new { |hash, key| 9000 }
moo(hash)

This passes:

expect(something)
  .to receive(:moo)
  .with(hash_with_defaults_including(stuff: 9000))

This does not pass:

expect(something)
  .to receive(:moo)
  .with(hash_including(stuff: 9000))

This is in preparation of landing denisdefreyne/cri#99, which makes use of these Hash defaults to specify default values for options.

This PR introduces #hash_with_defaults_including, which is similar to RSpec’s built-in #hash_including, but does not require the keys of `expected` to be present in `actual` -- what matters is that for all keys in `expected`, the value in `actual` and `expected` is the same.

    hash = Hash.new { |hash, key| 9000 }
    moo(hash)

This passes:

    expect(something)
      .to receive(:moo)
      .with(hash_with_defaults_including(stuff: 9000))

This does not pass:

    expect(something)
      .to receive(:moo)
      .with(hash_including(stuff: 9000))
@coveralls
Copy link

Coverage Status

Coverage remained the same at 93.373% when pulling f61a795 on ddfreyne:less-strict-hash-including-checking into b156261 on puppetlabs:master.

rodjek added a commit to rodjek/pdk that referenced this pull request Jun 4, 2019
cri 2.15.7 changed the behaviour of the options hash so that unspecified
flags are defaulted to an explicit `false` rather than being unset. From
the look of denisdefreyne/cri#94 though this
behaviour may be changing in the next release so lets pin cri to
a maximum of 2.15.6 for now until the behaviour stabilises and then we
can make the necessary changes.

/cc puppetlabs#674
@scotje
Copy link
Contributor

scotje commented Jul 2, 2019

Need to make sure this is updated everywhere and we should remove the Cri pin as part of the same PR.

@scotje scotje added the JIRA JIRA Ticket Created label Aug 13, 2019
@scotje
Copy link
Contributor

scotje commented Aug 13, 2019

@scotje
Copy link
Contributor

scotje commented Aug 20, 2019

Superseded by #731

@scotje scotje closed this Aug 20, 2019
logicminds pushed a commit to nwops/pdk that referenced this pull request Nov 30, 2020
cri 2.15.7 changed the behaviour of the options hash so that unspecified
flags are defaulted to an explicit `false` rather than being unset. From
the look of denisdefreyne/cri#94 though this
behaviour may be changing in the next release so lets pin cri to
a maximum of 2.15.6 for now until the behaviour stabilises and then we
can make the necessary changes.

/cc puppetlabs#674
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
JIRA JIRA Ticket Created needs-work
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants