Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
OCR grab of https://twitter.com/searls/status/1570471265944866816
--
Top of mind things I think are problematic about RSpec (literally just typing as think of stuff):
1. Its implementation is inscrutably complex, so if you have an issue, inspecting the source is not a productive solution
2. Its DSL defeats most attempts at automated introspection (Ctags, lang server, etc.) which means navigating the code is very difficult compared to tests of classes/methods
3. The DSL also allows for combinatorial explosions in runtime performance cost via incredibly terse and tidy APIs, most notably via shared_example _groups
4. The DSL provides numerous ways to structure tests and everyone has a different opinion (subject is great, subject is evil, let is good/bad, nesting is good/bad), leading to terrific inconsistency on projects as individuals express their own favorite way on the specs they write unless you dictate a style in a really authoritarian way.
5. Individuals express their own favorite way on the specs they write unless you dictate a style in a really an
The rspec-rails tie-ins are often years late to be updated to reflect changes in Rails itself, and when a failure occurs in that gem's indirection, it is very very difficult to workaround as user. It adds another point
of failure for little marginal value
6. Generating specs by looping over data structures is incredibly easy and convenient and often leads to an entire category of bugs (often pointed out by Jim Weirich in his talks) where you might loop over a data
structure to generate 100 specs and unwittingly realize that the final test case was actually generated and run 100 times
7. The above is caused by the fact that it's a two-pass system: first the specs are loaded and a tree of example groups is constructed dynamically, then a second pass in which the tests are executed. Because it's a
DSL and not class/method, it's very easy for developers to fail to grok that there are two runtime contexts and they will often be confused when describe or it or expect behaves differently based on
which method the current block is being passed to
8. People who advocate RSpec for the real Dan North BDD purpose it was created will very often tout its utility as a feature behavior elucidation tool, but in practice 99.9% of specs are just symmetric unit and
integration tests of code. This creates a lot of tension, as of the thing that RSpec is advertised as ("decouple your specs from the implementation class, describe the feature's outcomes instead!") often exacerbates
of the problem of unclear indirection (when I want to update class X, which spec do I need to drive that change through?). It's just another opportunity for ideological conflict to result in inconsistency and
confusion in the test suite.
I have a lot more but I didn't want to spend more than 10 minutes dunking on RSpec today
@randallreedjr
Copy link

randallreedjr commented Sep 22, 2022

Thank you for providing this! I noticed it looks like #4 is missing some text (missing text bolded):
4. The DSL provides numerous ways to structure tests and everyone has a different opinion (subject is great, subject is evil, let is good/bad, nesting is good/bad), leading to terrific inconsistency on projects as individuals express their own favorite way on the specs they write unless you dictate a style in a really authoritarian way.

This text appears to have been moved to the beginning of #5.

@randallreedjr
Copy link

randallreedjr commented Sep 22, 2022

Also a couple typos in #8.

as of the thing that RSpec

should be

as the thing that RSpec

Also

(when I want to update class X, which spec do X, need to drive that change through?)

should be

(when I want to update class X, which spec do I need to drive that change through?)

@peterc
Copy link
Author

peterc commented Sep 22, 2022

Thanks, I only chucked it through OCR at the time, just so there was an accessible version. I have made the fixes suggested - thanks!

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