Thanks, Phil, for the detailed and well thought-out answer. I appreciate the effort.
There was at least one comment in there that the Rails team intends to completely remove functional tests at some point in the future (I think the exact phrasing was on the order of “deprecating and eventually removing”. So that makes it sound like at some point I’m going to have to rewrite all my controller tests as request specs. But it also sounds like there is not universal agreement on the removal of controller tests (understatement?), and that there is a discrepancy between the concept that request specs should test all client-facing behavior, and the desire to test certain non-client-facing(?) behavior; after all, the goal of testing is to work towards bug-free code, and if you don’t test something you won’t know that it is bug-free. So I think, for me, the correct approach is to continue with the controller tests as-is (in other words, adding the ‘rails-controller-testing” gem, while putting new tests of client-facing behavior into request specs and non-client-facing tests into controller tests. Eventually, Rails will remove controller tests and when they do, they will have done the best they can for migrating controller tests to request specs. I did upgrade to rspec-rails 3.9 - no serious issues. > On Nov 30, 2020, at 9:05 AM, Phil Pirozhkov <[email protected]> wrote: > > > In Rails 5, the team changed controller tests to effectively be integration > tests (use URLs instead of actions), don’t test controller instance > variables, don’t test what template is rendered, etc. Instead, you should > test the contents of the page for specifics that indicate the request > completed as expected. > > With RSpec (at least with 3.1), controller tests in Rails 5 are still based > on the old unit test (Test::Case). So I’m wondering where I should go here? > As far as I remember, they still are even in rspec-rails 4.0. > > It should be noted that I’m just "passing through” Rails 5 on my way to Rails > 6 (or at least 5.2), as that may affect the answer to my question. > > Here are some of the alternatives I can think of: > 1) Stay with current software, use the "rails-controller-testing” to restore > template and assigns testing, and leave it alone for a future release. > 2) Stay with current software, rewrite all of the controller specs as request > specs (and abandon the controller specs). > 3) Upgrade to a newer version of RSpec that treats controller specs as > request specs (does this even exist?) and rework the controller specs to > follow the rules of request specs. > > Depends on how frequently `assigns` and `assert_template`. > As you have a different goal, and `rails-controller-testing` is extracted and > pretty well maintained, I guess you have better investment for your time than > to rewrite specs that work. > > version of RSpec that treats controller specs as request specs (does this > even exist?) > It doesn't to my best knowledge. > > There are a couple questions that inform this answer, and perhaps deserve to > be answered in their own right: > > 1) When all is said and done, what is the position of the RSpec team > regarding controller specs vs. request specs? > Controller specs are sometimes used as requests specs, and this lets you > easily shot you in your foot. I've just recently seen several `get` calls in > a single example, and memoization in the controller that remained between > those requests. > Rails core team worked hard to make request specs fast. I don't see any > reason not to use them. > > 2) Since it seems that, for at least awhile, RSpec and Rails were a bit at > odds regarding the nature of these tests, what minor versions of RSpec 3 > align with (are intended to be used with) which versions of Rails 5? > `rspec-rails` 4.x supports Rails 5 (and even 4.2). > There was a more reliable table than that in `rspec-rails` source somewhere, > but just by checking README.md of different maintenance branches of > `rspec-rails` 3.x > `rspec-rails` 3.0-3.5 Rails 3&4 > `rspec-rails` 3.5-3.9 Rails 3&4&5 > > It seems to me that these are relatively fundamental questions, and most > probably have been discussed/debated at great length, so if you can point me > to such a discussion that describes the official opinion of the RSpec team > (if there is one), that would be great. (I don’t need someone to write all > that up again if it already exists! I’ve seen a lot of blogs giving people’s > opinoins on controller unit specs vs. request specs vs. feature specs and I > don’t really want to touch the request spec vs. feature spec argument here.) > > For a start, there's an interesting discussion here > https://github.com/rspec/rspec-rails/issues/2373 > <https://github.com/rspec/rspec-rails/issues/2373> and here > https://github.com/rubocop-hq/rspec-style-guide/issues/113 > <https://github.com/rubocop-hq/rspec-style-guide/issues/113> > > -- > You received this message because you are subscribed to the Google Groups > "rspec" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rspec/CAAk5Ok-GjtsSQfyFGreEbLnhC_b53iJg15%2B6YKMiw7_Gm9mT0A%40mail.gmail.com > > <https://groups.google.com/d/msgid/rspec/CAAk5Ok-GjtsSQfyFGreEbLnhC_b53iJg15%2B6YKMiw7_Gm9mT0A%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "rspec" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/267C7FFE-A0FE-4028-8970-40B5E9AE8D8F%40pobox.com.
