Rails core - Apr 2013 - Rails' scaffold controller generator - should it test json format also?

(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!

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

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. ;)

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

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<https://github.com/chancancode/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.)

Godfrey

On Mon, Apr 15, 2013 at 9:30 AM, Steve Klabnik
<steve@steveklabnik.com>wrote:
> 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. ;)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscribe@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

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!

On Monday, April 15, 2013 12:30:08 PM UTC-4, Steve Klabnik
wrote:
>
> 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. ;) 
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

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!


On Monday, April 15, 2013 1:41:06 PM UTC-4, Godfrey Chan
wrote:
>
> 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<https://github.com/chancancode/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.)
>
> Godfrey
>
> On Mon, Apr 15, 2013 at 9:30 AM, Steve Klabnik
<st...@steveklabnik.com<javascript:>
> > wrote:
>
>> 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. ;)
>>
>> --
>> You received this message because you are subscribed to the Google
Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send
an
>> email to rubyonrails-co...@googlegroups.com <javascript:>.
>> To post to this group, send email to
rubyonra...@googlegroups.com<javascript:>
>> .
>> Visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.