As an observation, I’ve noticed that my unit specs tend to find breaking differences when I upgrade Ruby/Rails, while my request specs, feature specs, and system specs tend to find changes in how those test environments function from release to release. Of course, that’s once I have a stable version of my code. When making changes, I rely on the request/feature/system tests to determine the the code works as intended.
Maybe the reason that I’m so focused on unit tests is because my focus is on upgrading Ruby and Rails, rather than changes to my app’s functionality. > On Dec 6, 2020, at 10:10 AM, Jon Rowe <[email protected]> wrote: > >> If it’s that black-and-white that Request specs are to be preferred over >> Controller Specs, you should consider reflecting that in the documentation >> on RSpec Controller Specs. Right now, Controller Specs are documented very >> much the way they would have been before this debate appeared (and certainly >> before the moves were made by Rails to move away from controller tests). In >> fact, two of the four examples in the introduction to Controller Specs are >> about rendered templates and controller instance variables. (BTW, the >> Request Spec overview also mentions #render_template.) > > Thats because the documentation was likely written when controller specs > where the only option, and we as a team haven't gotten around to updating > them, nor am I likely to any time soon, but I'd happily review contributions > on this front. > I shall work on that, as I feel like if I had read what I’m envisioning there, I might have done things differently starting last summer (not placing blame -- I get that you can’t do everything, and you focused on functionality, and that without functionality there is no purpose for documentation). >> What I have done with Controller Specs is to focus on making sure that I >> test every piece of code that is in the Controller to ensure that they do >> what is expected of them, and the existence of robust controller specs has >> allowed me to discover and resolve a number of breaking changes > > All of which would have been apparent with request specs too. > I’m under the impression that testing which template was rendered and which variables assigned is considered verboten with request specs. Aren’t you supposed to test things like request status and actually rendered response (not how the response got rendered)? >> While a request spec will likely find a problem in your program’s behavior >> (if you’ve figured out enough of the logic to drive all the different paths >> through the code, which is not trivial when you’re focusing on the big >> picture of the request), > > A controller always executes in the context of the request, a controller spec > just skips parts of the stack, but not all of the stack, and can actually > introduce bugs where you pass in things which are not actually how rack > parses them. > When you’re testing a model, you’re not just testing the code you wrote in that model, you’re testing the part of Rails (AR/AM) that the code interacts with. So the argument that you aren’t just testing your controller code, you’re testing it’s interaction with Rack, AC, etc. seems specious to me. Further, to my mind, the mark of a good unit test is that it tests a bite-sized piece of code. When you write a request spec that tests the “entire stack”, you’re testing the templates, helpers, and models as well as the portions of the stack that Rails provides. And that would be fine if a bug in any of that will always reflect in the output. but sometimes you have a bug that hides another bug, and that will only be found by unit testing. Further, request Specs don't really test the entire stack, because they leave out the browser and JS, so it’s neither full-stack nor unit test. I feel like we need unit tests for virtually every piece of code and system tests (acceptance tests) to test that all the code when put together achieves the high-level goal. >> In Controller tests, I stub out almost everything not in the controller, so >> that it really is like a controller unit test. > > You can also stub out like that in a request spec, however thats not what I > mean by "controller specs are integration tests" a controller spec always has > part of the rack stack wrapped around it, and you don't er, control, the > initialisation of the controller. So it is never a unit test, you are always > integrating parts of Rails with your controller. > While it’s no doubt true that you can, the documentation says you should not stub in request specs. > I actually wrote proper controller unit tests as part of an experimental > setup, with an eye to improving controller specs in rspec-rails, however its > really difficult and involved a large knowledge of rails setup, thus its far > better to give in and accept the truth, that they are integration tests, and > treat them as such. > Just as writing tests for your models requires knowledge of how the model works. > You can still mock out your service layer in that context, (or go down the DI > route to allow control of your inner stack) but the Rails part is so coupled > to the router and rack stack you simply have to accept it (or, I guess PRs > welcome 😂) > I’m not going to tilt at THAT windmill! > Hope that helps > Jon > > Thanks for taking the time to respond. It must get tiring sometimes, defending yourself to folks who are second-guessing your decisions. Regards, Jack > > -- > 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/f1320e23-d12c-4e47-90ea-d80f6f598077%40www.fastmail.com > > <https://groups.google.com/d/msgid/rspec/f1320e23-d12c-4e47-90ea-d80f6f598077%40www.fastmail.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/DECDB55A-F674-4998-8EBF-43755D4833CE%40pobox.com.
