peterc · October 4, 2022 12:21 · randallreedjr · Sep 22, 2022 · randallreedjr · Sep 22, 2022
diff --git a/gistfile1.txt b/gistfile1.txt
 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
	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