[request]: Request Tests when testing Table-less Data

[MutableLoss]

I'm very curious to hear your thoughts on testing data that changes outside of the database, but is used above the model level. I know with request tests this would go against your practice of the skinny controller layout, but surely I'm not the only dev that has been put in front of a project where this is the case.

Along the same lines, Services are always easy as they can be included and tested in their own model/unit-tests, but request tests when working with such services where the return values come back to the frontend and not that obvious. I guess as long as there was a good known way to corner the data with a proc, that would be a great start.

EDIT: Just to give an idea of what I'm doing now for these cases, I'm using the rails-controller-testing gem to have access to the assigns method so that I can grab the instance variable and test against the data going in with the data being returned (in the assigns). I don't like to do this, since they are depreciated, and why I ask what can be done instead.

Thanks for everything, and I hope you consider this request!

[ruralocity]

Hey Dennis—so I haven't explicitly covered this in the book since I've always tried to keep it as close to The Rails Way as possible. I've also been hesitant to get too much into architectures that deviate from it, even when I use them myself.

But I think The Rails Way is finally evolving toward what you're talking about. I wouldn't be surprised to see services and other supporting-role objects become first class citizens of Rails in the next year or two. I've had a half-written blog post on this in my drafts folder for months now.

At my day job and side client projects, I write code so that I can cover the happy path and any other special cases with a small set of integration tests, then fill out most of the details with tiny, isolated, fast unit tests. Speaking personally, I had to feel the pain of testing complicated logic at higher levels to fully appreciate services and their like. But to properly extract code into services, I feel like I need the higher level test coverage, or at least parts of it. So it's kind of a chicken-and-egg thing, but I'm getting better at getting things right on the first try :)

Chapter 11 (hopefully coming tonight) touches on this some—if you have to write high-level tests to exercise some code, there's a good chance that the application code lives in the wrong place. I don't get too in depth on it, though. I may someday, but I think I'll kick the tires with some blog posts first before applying to the book with more depth.

Hope that helps!

[MutableLoss]

Huge thanks Aaron, and yes!

I totally get that, and thank you so much for the reply and feedback! I definitely can't wait for the blog post when it comes out. 😉

While I did do integration tests, the meat of the service testing ended up being in the unit-tests. For this specific test suite I did exactly as you mentioned, putting the service into the test environment as a spec service then using the service class as a first-class citizen, allowing me to test the methods against the logic itself within a model/unit-test outside of the app. I didn't have a huge issue with this as a whole, and considering my situation I found it to be beneficial to learning the project code in question.

To give that last sentence context, this was an scenario I ran across with my day job as a Rails dev, as I was brought into a new team with pre-existing monolithic projects, but without any tests. Having a TDD/BDD background with other languages, I took on the role of handling tests, but to the point basically having to deal with what is already there. Since I know this is not an uncommon scenario for developers, I'm very curious what you think should be the mindset in these situations? Find a way to test it with the current arch, sacrifice coverage by not testing it, or simply find another way to test it?

Huge thanks for the insight, and hope this helps on your end in some way or another!