(Forgive me if this is incorrect, because I recognized this initially as something in Rails 4.0.0.beta1 and have just done a cursory look over the latest generator code.)
Noticed in Rails 4 that the test generated for a scaffold controller only tests the html format instead of both html and json:
https://github.com/rails/rails/blob/3f9baeb2ec08138a0da09870ae60fd6b8165c07f/railties/lib/rails/generators/rails/scaffold_controller/templates/controller.rb
It was like that before, but now it is less obvious that it isn’t testing it because of the jbuilder integration 3 months ago here: https://github.com/rails/rails/commit/3bfd99defb559af0b017ee920ca714aa1e367fdd#railties/lib/rails/generators/rails/scaffold_controller/templates/controller.rb
I know that there is nothing in the code of the generated controller that itself is json-specific, so any generated tests for json format specific behavior (1) would be testing jbuilder, and jbuilder already has tests, and (2) if the generated test forces testing of json, then people that don’t care about json or have overwritten the Rails 4 controller generator template would also need to either modify the generated tests or also modify the controller test generator template to keep it from testing json format.
However, I see neither of these as reasons that the controller tests should not test json format, since jbuilder views are created as part of the generated scaffold that need to be tested (that is part of the point of the generated test), and even if it doesn’t need to be tested because we know the default version should work, it would be helpful to show new users how to test both the html and json format of the controller, imo, to ensure that jbuilder views are valid and everything is working correctly as a basic test of the newly generator scaffold.
So,
Question #1: What do you think of that?
Question #2: Actions ‘new’ and ‘edit’ could theoretically respond in json format because the routes are there, but there are no jbuilder views for those (since they really wouldn’t be used), so they fail. Should the generated restful route be more complicated to disable/not enable routs for new and edit actions for non-html format? Or should that be left as-is and if it was decided that there should be json tests, then there should be no tests for new/edit in json?
Thanks!
The purpose of generating tests is more about giving a little example
than testing it thoroughly. Given, as you say, jBuilder has tests,
doesn't seem tremendously useful.
(since they really wouldn't be used)
Hypermedia APIs will use these. 
TL;DR… If someone is going to add this, I’m definitely a +1 (fwiw)
I completely agree with Steve that the generated tests are just examples, but from there I drew the opposite conclusion (unless I misunderstood what you said). I might be biased (I wrote json_expressions), but I think testing JSON responses is important, especially when they are used as an API consumed by other components of your system. For that reason, I think it’s definitely worth putting in some examples and guidance around testing JSON responses.
There are a lot of implementation problems to think about such as (even when it’s just serving the role of an example/placeholder, such as:
-
What (not) to cover
-
Unit tests or integration tests
-
How to assert on the value of the JSON response (I don’t think it’s worth pulling in any dependencies here for this, so what I meant is more along the lines of some pure-Ruby idiom that would work well for the simple cases)
I don’t think these are particularly hard problems to solve. Granted, not everyone would like it, some people would prefer to do it differently and some simply won’t care. However, I think some convention here is better than no convention.
It was a bit tricky to do before, but since we now picked a “winner” (jbuilder) for inclusion with core as the default, it should make things easier, so I think this is a pretty good time to add this. (If we do this right, other gems would just hook in to the generators and provide different test cases around their conventions.)
Steve,
Mostly, I would just like a basic set of reference tests for how Rails expects that a controller that provides JSON services should act, and even though the jbuilder has tests, I don’t see much for testing that a controller’s json API is behaving as expected in:
https://github.com/rails/jbuilder/tree/c3f8ef7bbdb88bec2bcfc27100da63ef6aad4cf1/test
Specifically, I’d like to test that a controller using restful_json is responding as close as possible to a normal Rails scaffold-generated controller when using the default configuration, even for each of the different Rails versions: 3.1.x, 3.2.x, 4.0.x (for now 4.0.0.beta1 and edge).
I knew that the scaffold generated tests were light in previous versions of Rails, but I somewhat saw that as an artifact of Rails 1.x-3.x really focusing on generating HTML pages and forms and those forms interacting with a restful API that would return HTML. That is still the case, but now that a generated scaffold is producing jbuilder views, the JSON API isn’t some “option you could use if you want” but rather an integral part of the app. I think that the generated scaffold test should test everything that is being provided, even if only in a very basic manner. And, for my current purposes, I’d actually like something that tests the behavior to a greater extent (testing each method of the scaffold generated controllers actions in JSON format for success and error conditions; I think that an example test could provide this without going overboard.
Regarding new and edit actions in JSON format by generated scaffold controllers, since JBuilder currently only generates index and show:
https://github.com/rails/jbuilder/tree/c3f8ef7bbdb88bec2bcfc27100da63ef6aad4cf1/lib/generators/rails/templates
will those have to be manually added by the user if they wish to use hypermedia APIs vs. just generating a scaffold?
Thanks!
Thanks!
but since we now picked a “winner” (jbuilder) for inclusion with core as the default
I’ve added JBuilder and (vanilla) Strong Parameters support into restful_json recently. I still like ActiveModel::Serializers for the view and Permitters (twinturbo’s construct we’re using, hopefully soon will get them into a gem) as an OO wrapper around Strong Parameters.
Maybe at some point we’d switch to JBuilder and plain Strong Parameters. It’s nice to have options, and it’s also nice to have a default!
