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

Using Given/When/Then side-by-side with before/it? #47

Open
ronen opened this issue Jan 9, 2015 · 6 comments
Open

Using Given/When/Then side-by-side with before/it? #47

ronen opened this issue Jan 9, 2015 · 6 comments

Comments

@ronen
Copy link
Contributor

ronen commented Jan 9, 2015

I've found that depending on what I'm testing in some cases I might prefer the traditional rspec context/it flow, and in other cases Given/When/Then flow. Or I might want to gradually migrate a file full of tests from one to the other, so while in transition the file might have some of each kind.

It would be nice if the README could document whether & how it's OK to do something like:

describe "Thing" do
  context "traditional" do
    before(:each) { setup something }
    it "works" do
       try something
       expect to get the proper result
    end
  end
  context "newfangled" do 
    Given { setup other }
    When { try other }
    Then { get the other result }
  end
end

That seems like it would work (and I think it does), but things seems like they'd get messy if there was a Given nested inside a context with a before or vice versa. (Or maybe there's a well-defined way in which it can work?) Though I imagine before(:suite) hooks wouldn't be a problem.

Anyway, WBN for rspec-given to take a firm stand on what's expected to work.

@ronen ronen mentioned this issue Jan 9, 2015
3 tasks
@searls
Copy link

searls commented Jan 9, 2015

In [email protected], this was not encouraged but worked perfectly well because there was no interplay between the given/when/then methods.

In 2.x there may be subtle problems depending on what is combined, particularly in cases where a before or let raises error and is in turn only invoked by a Then. But honestly, the nuance needed to keep them working is mostly wasted as long as folks keep the given and traditional DSLs to mostly-separate contexts (which works fine)

@ronen
Copy link
Contributor Author

ronen commented Jan 9, 2015

Oh, your response beat me to it -- i was just about to close this and repost on the new repo. WIll continue discussing here...

as long as folks keep the given and traditional DSLs to mostly-separate contexts (which works fine)

So should the README have a short section such as:

## Combining Given/When/Then with the traditional before/let/it DSL

Given/When/Then clauses and traditional rspec DSL blocks can coexist in the same suite,
as long they are in separate contexts, without any shared `before(:each)` or `let` blocks.

Shared `before(:all)` and `before(:suite)` blocks are fine and will apply normally.

Is that last sentence true?

@searls
Copy link

searls commented Jan 9, 2015

I waffle on whether it's worth addressing in that light in the README. :+meh: for now

@ronen
Copy link
Contributor Author

ronen commented Jan 9, 2015

Clearly not a huge deal. But I'd lean towards including something like it for two reasons:

  • It's really not completely 100% obvious -- I really don't know whether before(:all) will work in a context that has Given/When/Then in it.
  • It might make rspec-given more appealing if potential users know that it's not an all-or-nothing change, i.e., that including rspec-given won't preclude using the traditional DSL in the same suite.

@searls
Copy link

searls commented Jan 9, 2015

I think the latter is a compelling point we need to make, but I'm wary of saying it loudly and proudly until we really understand the constraints on the former

@ronen
Copy link
Contributor Author

ronen commented Jan 9, 2015

Oh... I thought it was just me who didn't understand :) In that light, yeah I'd agree hold off proclaiming anything that ain't necessarily so.

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