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

Use contexts #3

Open
andreareginato opened this Issue Oct 3, 2012 · 29 comments

Comments

Projects
None yet
@andreareginato
Collaborator

andreareginato commented Oct 3, 2012

Write your thoughts about the "use contexts" best practice.

@andyw8

This comment has been minimized.

Show comment
Hide comment
@andyw8

andyw8 Oct 4, 2012

Deeply nested contexts can be confusing. I wouldn't use any more than 2 levels.

andyw8 commented Oct 4, 2012

Deeply nested contexts can be confusing. I wouldn't use any more than 2 levels.

@andrewhavens

This comment has been minimized.

Show comment
Hide comment
@andrewhavens

andrewhavens Oct 5, 2012

I agree with this best practice, but I feel there should also be example code of how to set up the context. The context method doesn't do anything by itself, just makes it more readable.

andrewhavens commented Oct 5, 2012

I agree with this best practice, but I feel there should also be example code of how to set up the context. The context method doesn't do anything by itself, just makes it more readable.

@flov

This comment has been minimized.

Show comment
Hide comment
@flov

flov Oct 9, 2012

I agree with @andyw8 and disagree with the rule.
If there would be only one it block inside the context block, it reads much easier with using one it instead of using context and it.
It also requires you to setup the conditions in a before block which is another two lines just for before do and end

flov commented Oct 9, 2012

I agree with @andyw8 and disagree with the rule.
If there would be only one it block inside the context block, it reads much easier with using one it instead of using context and it.
It also requires you to setup the conditions in a before block which is another two lines just for before do and end

@adarsh

This comment has been minimized.

Show comment
Hide comment
@adarsh

adarsh Oct 19, 2012

I disagree with using "should" in describe blocks.

Do or do not - there is no "should".

adarsh commented Oct 19, 2012

I disagree with using "should" in describe blocks.

Do or do not - there is no "should".

@adarsh

This comment has been minimized.

Show comment
Hide comment
@adarsh

adarsh Oct 19, 2012

Edit: Wait - you already have this guideline here.

Why is it not used in this example (or others consistently)?

adarsh commented Oct 19, 2012

Edit: Wait - you already have this guideline here.

Why is it not used in this example (or others consistently)?

tony612 added a commit to tony612/betterspecs that referenced this issue Mar 19, 2013

@kikito

This comment has been minimized.

Show comment
Hide comment
@kikito

kikito May 1, 2013

This particular example confuses me.

it 'has 200 status code if logged in' do
  response.should respond_with 200
end

=>

context 'when logged in' do
  it { should respond_with 200 }
end

My concern is that response has magically dissapeared. Where is it?

kikito commented May 1, 2013

This particular example confuses me.

it 'has 200 status code if logged in' do
  response.should respond_with 200
end

=>

context 'when logged in' do
  it { should respond_with 200 }
end

My concern is that response has magically dissapeared. Where is it?

@LandonSchropp

This comment has been minimized.

Show comment
Hide comment
@LandonSchropp

LandonSchropp Jul 7, 2013

What's the best way to go about setting up the context? Should I just be using before? In the example, the context is magically set up.

LandonSchropp commented Jul 7, 2013

What's the best way to go about setting up the context? Should I just be using before? In the example, the context is magically set up.

@alexandru-calinoiu

This comment has been minimized.

Show comment
Hide comment
@alexandru-calinoiu

alexandru-calinoiu Aug 1, 2013

It should be mentioned somewhere that you need shoulda included as gem for this matchers to actually work

alexandru-calinoiu commented Aug 1, 2013

It should be mentioned somewhere that you need shoulda included as gem for this matchers to actually work

@warmwaffles

This comment has been minimized.

Show comment
Hide comment
@warmwaffles

warmwaffles Aug 1, 2013

@kikito response is the subject. Since this would be in a controller test, it gets assigned as the subject.

warmwaffles commented Aug 1, 2013

@kikito response is the subject. Since this would be in a controller test, it gets assigned as the subject.

@russellsilva

This comment has been minimized.

Show comment
Hide comment
@russellsilva

russellsilva Aug 26, 2013

I agree that the comment by @Balauru should be incorporated. Also the clarification by @warmwaffles would be nice too. These things may be obvious for experience Rails hackers but they aren't clear for a newbie.

russellsilva commented Aug 26, 2013

I agree that the comment by @Balauru should be incorporated. Also the clarification by @warmwaffles would be nice too. These things may be obvious for experience Rails hackers but they aren't clear for a newbie.

@warmwaffles

This comment has been minimized.

Show comment
Hide comment
@warmwaffles

warmwaffles Aug 26, 2013

@russellsilva essentially in the background this happens with controller tests:

subject { response }

If you wish to be more explicit, then by all means, use response

warmwaffles commented Aug 26, 2013

@russellsilva essentially in the background this happens with controller tests:

subject { response }

If you wish to be more explicit, then by all means, use response

@tubbo

This comment has been minimized.

Show comment
Hide comment
@tubbo

tubbo Sep 30, 2013

I really fail to see how one is any better than the other. You're adding extra syntax and work for the program just to save yourself a few characters? Also forgot to mention that shoulda isn't part of RSpec and therefore it {should.. doesn't work in straight RSpec. So now I have to load a whole 'nother gem just to save a few extra characters?

Most of these tips for writing more clear specs are appreciated, and make a lot of sense. But this one in particular struck me as a little snake oily.

tubbo commented Sep 30, 2013

I really fail to see how one is any better than the other. You're adding extra syntax and work for the program just to save yourself a few characters? Also forgot to mention that shoulda isn't part of RSpec and therefore it {should.. doesn't work in straight RSpec. So now I have to load a whole 'nother gem just to save a few extra characters?

Most of these tips for writing more clear specs are appreciated, and make a lot of sense. But this one in particular struck me as a little snake oily.

@siwka

This comment has been minimized.

Show comment
Hide comment
@siwka

siwka Oct 23, 2013

I am new to rspec. First I type a good solution and in result I have obvious for experienced users 'undefined method context'. Where is application of 'devoted to how to create a great RSpec test suite'? I wish to find reliable resource.

siwka commented Oct 23, 2013

I am new to rspec. First I type a good solution and in result I have obvious for experienced users 'undefined method context'. Where is application of 'devoted to how to create a great RSpec test suite'? I wish to find reliable resource.

@warmwaffles

This comment has been minimized.

Show comment
Hide comment
@warmwaffles

warmwaffles Jan 9, 2014

How are nested contexts supposed to be done?

context 'when something is set' do
  context 'and when another thing is set' do
  end
end

is it proper to use and in the description?

warmwaffles commented Jan 9, 2014

How are nested contexts supposed to be done?

context 'when something is set' do
  context 'and when another thing is set' do
  end
end

is it proper to use and in the description?

@tubbo

This comment has been minimized.

Show comment
Hide comment
@tubbo

tubbo Jan 9, 2014

I usually don't write "and" in my context descriptions, but if I could alias context "when #{message}" to when, I would :)- T

On Thu, Jan 9, 2014 at 1:15 PM, Matthew Johnston notifications@github.com
wrote:

How are nested contexts supposed to be done?

context 'when something is set' do
  context 'and when another thing is set' do
  end
end

is it proper to use and in the description?

Reply to this email directly or view it on GitHub:
#3 (comment)

tubbo commented Jan 9, 2014

I usually don't write "and" in my context descriptions, but if I could alias context "when #{message}" to when, I would :)- T

On Thu, Jan 9, 2014 at 1:15 PM, Matthew Johnston notifications@github.com
wrote:

How are nested contexts supposed to be done?

context 'when something is set' do
  context 'and when another thing is set' do
  end
end

is it proper to use and in the description?

Reply to this email directly or view it on GitHub:
#3 (comment)

@warmwaffles

This comment has been minimized.

Show comment
Hide comment
@warmwaffles

warmwaffles Jan 9, 2014

You can't use when with a lower case, however you can alias context to be When, however I don't think this is a good idea.

warmwaffles commented Jan 9, 2014

You can't use when with a lower case, however you can alias context to be When, however I don't think this is a good idea.

@LandonSchropp

This comment has been minimized.

Show comment
Hide comment
@LandonSchropp

LandonSchropp Jan 9, 2014

Yeah, I realized when was a reserved word almost immediately after I typed that. My bad.

LandonSchropp commented Jan 9, 2014

Yeah, I realized when was a reserved word almost immediately after I typed that. My bad.

@mhluongo

This comment has been minimized.

Show comment
Hide comment
@mhluongo

mhluongo Jan 10, 2014

The switch from inline matching to custom matchers from the shoulda gem in the before/after examples are extremely misleading for those of us new to RSpec.

mhluongo commented Jan 10, 2014

The switch from inline matching to custom matchers from the shoulda gem in the before/after examples are extremely misleading for those of us new to RSpec.

@warmwaffles

This comment has been minimized.

Show comment
Hide comment
@warmwaffles

warmwaffles Jan 10, 2014

Personally, I stay away from shoulda matchers. They are confusing and need to be avoided.

warmwaffles commented Jan 10, 2014

Personally, I stay away from shoulda matchers. They are confusing and need to be avoided.

@TigerWolf

This comment has been minimized.

Show comment
Hide comment
@TigerWolf

TigerWolf Mar 24, 2014

This is inconsistent with http://betterspecs.org/#expect

It should be updated to follow the other guideline.

TigerWolf commented Mar 24, 2014

This is inconsistent with http://betterspecs.org/#expect

It should be updated to follow the other guideline.

@ZenCocoon

This comment has been minimized.

Show comment
Hide comment
@ZenCocoon

ZenCocoon Apr 10, 2014

As a one liner syntax, I would rather recommend is_expected.to instead of should. While a little more verbose, it would keep the logic more consistent.
Cf. https://www.relishapp.com/rspec/rspec-core/v/3-0/docs/subject/one-liner-syntax

ZenCocoon commented Apr 10, 2014

As a one liner syntax, I would rather recommend is_expected.to instead of should. While a little more verbose, it would keep the logic more consistent.
Cf. https://www.relishapp.com/rspec/rspec-core/v/3-0/docs/subject/one-liner-syntax

@pedz

This comment has been minimized.

Show comment
Hide comment
@pedz

pedz Oct 5, 2014

For this particular topic (and perhaps others), I would like to see what rspec prints out. That would make me better able to evaluate the idea myself. Often I write specs and then rewrite them because the output when the test is run is useless.

pedz commented Oct 5, 2014

For this particular topic (and perhaps others), I would like to see what rspec prints out. That would make me better able to evaluate the idea myself. Often I write specs and then rewrite them because the output when the test is run is useless.

@xirukitepe

This comment has been minimized.

Show comment
Hide comment
@xirukitepe

xirukitepe Jun 6, 2015

Is it really okay to have nested context blocks?

xirukitepe commented Jun 6, 2015

Is it really okay to have nested context blocks?

@onebree

This comment has been minimized.

Show comment
Hide comment
@onebree

onebree Jun 6, 2015

Contributor

@xirukitepe I think it depends on your workflow and preference. At work, we use Capybara integration tests. Capybara DSL uses feature in place of context. Both work, but it just adds readibility to the spec. For us, a feature is a page (pretty much the controller used) in the app. I then create sub-contexts, like: context "SAD PATHS", because we do not use the it {should not} style. This way we can read the output and know if a test is for happy or sad paths

Do know, if you run random specs, they will be randomized as follows:

  1. By spec file
  2. By context (or feature or whatever DSL you use)
  3. By examples within the context

This means, if you have 2 contexts (one saying "Users page", and another saying "sad paths"), what will be randomized is:

  1. Spec file
  2. top level context
  3. second level context
  4. (and so on)
  5. examples
Contributor

onebree commented Jun 6, 2015

@xirukitepe I think it depends on your workflow and preference. At work, we use Capybara integration tests. Capybara DSL uses feature in place of context. Both work, but it just adds readibility to the spec. For us, a feature is a page (pretty much the controller used) in the app. I then create sub-contexts, like: context "SAD PATHS", because we do not use the it {should not} style. This way we can read the output and know if a test is for happy or sad paths

Do know, if you run random specs, they will be randomized as follows:

  1. By spec file
  2. By context (or feature or whatever DSL you use)
  3. By examples within the context

This means, if you have 2 contexts (one saying "Users page", and another saying "sad paths"), what will be randomized is:

  1. Spec file
  2. top level context
  3. second level context
  4. (and so on)
  5. examples
@nagi

This comment has been minimized.

Show comment
Hide comment
@nagi

nagi Dec 7, 2015

How about amending:

When describing a context, start its description with "when" or "with"

... to ...

When describing a context, start its description with "when", "with", or "without"

Not so hot (in my opinion)

context 'with sprinkles' ...
context 'when there are no sprinkles on top' ...

Better (again, in my opinion)

context 'with sprinkles' ...
context 'without sprinkles' ...


🍦 🍨 🍧

nagi commented Dec 7, 2015

How about amending:

When describing a context, start its description with "when" or "with"

... to ...

When describing a context, start its description with "when", "with", or "without"

Not so hot (in my opinion)

context 'with sprinkles' ...
context 'when there are no sprinkles on top' ...

Better (again, in my opinion)

context 'with sprinkles' ...
context 'without sprinkles' ...


🍦 🍨 🍧

@onebree

This comment has been minimized.

Show comment
Hide comment
@onebree

onebree Dec 7, 2015

Contributor

@nagi I like your idea. How about submitting a pull request with the change?

Contributor

onebree commented Dec 7, 2015

@nagi I like your idea. How about submitting a pull request with the change?

@nagi

This comment has been minimized.

Show comment
Hide comment
@nagi

nagi Dec 7, 2015

@onebree Great, thanks! #157

nagi commented Dec 7, 2015

@onebree Great, thanks! #157

@mvz

This comment has been minimized.

Show comment
Hide comment
@mvz

mvz Nov 23, 2017

I'm confused what this particular guideline is about: The good/bad example both adds the context and uses an anonymous it block.

mvz commented Nov 23, 2017

I'm confused what this particular guideline is about: The good/bad example both adds the context and uses an anonymous it block.

@pedroadame

This comment has been minimized.

Show comment
Hide comment
@pedroadame

pedroadame Jan 25, 2018

+1 @warmwaffles about writing nested context with context 'and when...'.

pedroadame commented Jan 25, 2018

+1 @warmwaffles about writing nested context with context 'and when...'.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment