What is the argument against using before, let and subject in RSpec tests? [closed]

by

Interesting question; something that I want to know more about as well…. So dug in a bit, and here is what I uncovered:

Thoughtbot style guide dictum about let, etc.

  1. In an earlier version of the style guide, there’s more to that statement:

    Avoid its, let, let!, specify, subject, and other DSLs. Prefer explicitness and consistency.

  2. ThoughtBot folks made a post on let name let’s not. See also the link to the Github Commit Comment conversation

  3. On one of their recent podcasts Joe Ferris, the CTO of ThoughtBot, explains why it’s not a good idea to use let and subject. Check out the podcast titled Something Else Was Smellier from the 27m37s mark onwards for the next 5 minutes.

  4. Testing Anti-pattern ‘Mystery Guest’ which is dealt with in detail in an older ThoughtBot blogpost is the main reason for why not to use let and its cousins.

To summarize my understanding of all the above very succinctly:

Using let et al makes it difficult to understand what’s happening
within the test on a quick glance, and requires the person to spend
some time in making the connections.

Write tests such that it is easy to understand without much effort.

In addition, using let liberally in tests results in over-sharing among the tests, as well as makes implicit common fixtures – i.e. having a common fixture to start with for every test being written even when it does not apply.

before(:all)

The argument against using before(:all) is straight-forward. As explained in the old rspec documentation:

Warning: The use of before(:all) and after(:all) is generally discouraged because it introduces dependencies between the Examples. Still, it might prove useful for very expensive operations if you know what you are doing.

before(:all) gets executed only once at the start of the ExampleGroup. As such there is a potential to inadvertently introduce dependencies between the Examples. Thoughtbot’s assertion about the tests not being easy to understand applies to this as well.

In conclusion, the advise for writing better specs seems to be:

  1. Write tests such that they are easy to understand on a quick glance.
  2. Know what you are doing.

Leave a Comment

tech