Re: What is the best way to replace 'its' ?

[Myron Marston]

On Jan 29, 10:38 pm, jcar...@mdsol.com wrote:
> It seems that going forward 'its' is gonna be deprecated.
> I would like to know what is the best way to replicate its behaviour.
>
> For instance I have this:
>
>  context 'new article' do
>        subject(:article) { Article.new }
>        its(:for_magazine?) { should be_false }
>        its(:total_pages) { should == 1 }
>        its(:current_page_number) { should == 1 }
>        its(:has_next_page?) { should be_false }
> end
>
> if I change to somethig like
>  it { expect(article.for_magazine?).to be false }
>
> it prints out   'new article'  should be false
> Which makes no sense
>
> if I do
>
>  context "for magazine?" do
>     it …..
>  end
>
> prints well but is very verbose
>
> is there any other alternative?

Here's what I wrote about `its` recently when asked on Twitter about
it:

https://gist.github.com/4503509

There's already a gem that provides `its` plus some additional
features:

https://github.com/dnagir/its

...so you're welcome to use that if you feel like you need this
feature.

As for how I'd approach this without using `its`...that's hard to say
without seeing the bigger picture of what the behavior of `Article` is
and what role it plays in your system. I might do something like
this, though:

describe Article do
context 'when instantiated with no arguments' do
it 'is not for a magazine' do
expect(Article.new).not_to be_for_magazine
end

it 'has only one page' do
article = Article.new
expect(article.total_pages).to eq(1)
expect(article.current_page_number).to eq(1)
expect(article).not_to have_next_page
end
end
end

Maximizing terseness is not one of the primary things I aim for when I
write specs.

HTH,
Myron

[jca...@mdsol.com]

Awesome answer.
I have being testing the Given/When/Then framework but the Then prints out very ugly so I do not think I will use it.

Your solution is good, I thought that doing several expectations inside an 'it' was considered bad style.
But I think I understand the general idea, what I really want to check is the fact that it has only one page and this high level check can be decomposed on these small checks in this case.

Thank you very much.

[Myron Marston]

On Jan 30, 12:33 am, jcar...@mdsol.com wrote:
> Awesome answer.
> I have being testing the Given/When/Then framework but the Then prints out
> very ugly so I do not think I will use it.
>
> Your solution is good, I thought that doing several expectations inside an
> 'it' was considered bad style.
> But I think I understand the general idea, what I really want to check is
> the fact that it has only one page and this high level check can be
> decomposed on these small checks in this case.
>
> Thank you very much.

I believe the "one expectation per example" (or "one assertion per
test") guideline was born as a reaction to a testing style that would
pile up many unrelated assertions/expectations in a single test/
example, which made it hard to understand what behavior was failing
when you get failure output. It's useful as an exercise to try to
structure things using "one expectation per example", but I think it's
an unhelpful guideline as a general rule.

betterspecs.org lists this as a "best practice" (along with some other
things with which I disagree). I commented on a github issue thread
what I would say instead:

https://github.com/andreareginato/betterspecs/issues/5#issuecomment-9110114

* In isolated unit specs, you want each example to specify one (and
only one) behavior. Multiple expectations in the same example are a
signal that you may be specifying multiple behaviors.

* In tests that are not isolated (e.g. ones that integrate with a DB,
an external webservice, or end-to-end-tests), you take a massive
performance hit to do the same setup over and over again, just to set
a different expectation in each test. In these sorts of slower tests,
I think it's fine to specify more than one isolated behavior.

As in all things, software engineering is about tradeoffs, and this is
no exception. It's bad to encourage cargo-cult thinking here.

[David Chelimsky]

On Wed, Jan 30, 2013 at 10:06 AM, Myron Marston <myron....@gmail.com> wrote:

On Jan 30, 12:33 am, jcar...@mdsol.com wrote:
> Awesome answer.
> I have being testing the Given/When/Then framework but the Then prints out
> very ugly so I do not think I will use it.
>
> Your solution is good, I thought that doing several expectations inside an
> 'it' was considered bad style.
> But I think I understand the general idea, what I really want to check is
> the fact that it has only one page and this high level check can be
> decomposed on these small checks in this case.
>
> Thank you very much.

I believe the "one expectation per example" (or "one assertion per
test") guideline was born as a reaction to a testing style that would
pile up many unrelated assertions/expectations in a single test/
example, which made it hard to understand what behavior was failing
when you get failure output.

Separate from whether the expectations are related, the guideline is about understanding context. If 4 examples with one expectation in each all fail at the same time, you have 4 data points which provide insight into the problem. If all 4 expectations are in one example, you only get 1 data point.

The biggest offences of this, however, are scenarios in which the subject's state is changed multiple times with expectations at each state.