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

Top level tear_down ignored unless set_up also present #111

Closed
duncan-bayne opened this issue Aug 18, 2016 · 5 comments
Closed

Top level tear_down ignored unless set_up also present #111

duncan-bayne opened this issue Aug 18, 2016 · 5 comments

Comments

@duncan-bayne
Copy link

duncan-bayne commented Aug 18, 2016

In the following code, tear_down is never executed:

Pact.provider_states_for 'Things' do
  # this never runs!
  tear_down do
    VCR.eject_cassette
    VCR.turn_off!
    PactProviderSetup::ElasticsearchIndex.delete_indices!
  end

  # provider states here ...
end

In order to have it execute, I need to add an empty set_up call at the top level:

Pact.provider_states_for 'Things' do
  set_up {}

  # this now runs!
  tear_down do
    VCR.eject_cassette
    VCR.turn_off!
    PactProviderSetup::ElasticsearchIndex.delete_indices!
  end

  # provider states here ...
end

Versions of things:

    pact (1.9.3)
      awesome_print (~> 1.1)
      json
      pact-mock_service (~> 0.8)
      pact-support (~> 0.5.7)
      rack-test (~> 0.6.2)
      randexp (~> 0.1.7)
      rspec (>= 2.14)
      term-ansicolor (~> 1.0)
      thor
      webrick

    ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-darwin14]
@bethesque
Copy link
Member

Obviously crappy coding...

@bethesque
Copy link
Member

Fixed. Funnily enough, there are a few lines of code in there (not the bug obviously :P) that I remember you helping with.

@bethesque
Copy link
Member

Released 1.9.4.

@duncan-bayne
Copy link
Author

Thanks for the quick fix! 😄

Wow, that must have been years ago. Time flies.

I've seen a couple of variations of this bug in various codebases recently, and have become a convert to @simonrussell's approach of (almost) always using fetch instead of []. Makes me think a lot more carefully about default / nil cases. Maybe that says more about me than about the language 😄

@bethesque
Copy link
Member

Yeah, I like to use fetch in tests, because otherwise you risk getting nil == nil false positives.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants