Rails core - May 2012 - Simple idea for simplifying client-side code test built-in in Rails

A while ago I started a topic here asking for including any framework 
for testing client-side code built into Rails and integrated to 
generators as well.

Rails 4 would be a great opportunity for including such a feature.

By that time, most (including me) have suggested Jasmine as such a 
framework. But actually I don''t really care which framework would be 
chosen as it could be easily replaced.

For example, it is pretty clear for me that Konacha has set the proper 
way of dealing with such kind of tests:

https://github.com/jfirebaugh/konacha

Basically its approach is to provide two useful tasks:

konacha:serve - starts an isolated application sharing the asset 
pipeline for in-browser test runner;
konacha:run - suitable for CI, although I''m still not sure what
approach
to take for implementing such task, so this could be added in the 
future, after the other task, which approach is more obvious to opt for.

But it has a single issue that is too easy to be fixed - it is not 
framework agnostic:

https://github.com/jfirebaugh/konacha/issues/37

If Rails provided the idea used by Konacha built in, but providing hooks 
so that other gems could easily set up the template for their JavaScript 
runners, this would be a great solution to client-side integrated test 
solution.

Rails wouldn''t even have to add support for common libraries, like 
Sinon.js or Jasmine. It could include any test runner.

For example, since Rails opts for test/unit assertions style as well as 
jQuery as default choices, it would make sense to keep with that style 
by choosing QUnit, which is also developed by the jQuey team and uses 
the assertions style:

https://github.com/jquery/qunit
http://docs.jquery.com/QUnit

I wouldn''t use the default QUnit in the same way I don''t use
test/unit
for my Ruby tests, but it should be trivial to just add a gem composed 
by one or two files that would enable me to use Jasmine while taking 
advantage of the assets pipeline.

Of course I can already have something like this working in current 
Rails, but the approach taken by Konacha seems so straightforward, clean 
and simple to me that it seems that every runner should take a similar 
approach basically changing only some settings like the template of the 
runner as well as the pattern where to look for test files.

It doesn''t make sense for all similar gems to rewrite all the common 
infrastructure. And it would be great to transmit the idea that 
client-side code testing is as much important as server-side testing.

Actually chances are that client-side code will be more and more 
important as time passes. And still, Rails seems to be ignoring that by 
not providing tests for the CoffeeScript generated assets.

I wasn''t sure about what approach to take at the time I first proposed 
including any JavaScript testing framework into Rails, but now I''m 
pretty convinced that Konacha''s simple approach is the correct one to
take.

We would just need to add some hooks to make it framework-agnostic, and 
that shouldn''t be hard to do.

Any thoughts about this?

Kind regards,
Rodrigo.

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

+1 from me. Rails did a lot to bring testing to web apps, people are
now doing JS testing, we should have some kind of JS story.

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

Here is an example of what I was talking about. Framework agnostic and 
easy to extend:

https://github.com/rosenfeld/rails-sandbox-assets

As you can see, adding support for the Jasmine test runner on top of the 
gem above is pretty simple:

https://github.com/rosenfeld/rails_sandbox_jasmine

Any chances of getting something like this built into Rails 4?

Cheers,
Rodrigo.

Em 23-05-2012 00:05, Rodrigo Rosenfeld Rosas escreveu:
> A while ago I started a topic here asking for including any framework 
> for testing client-side code built into Rails and integrated to 
> generators as well.
>
> Rails 4 would be a great opportunity for including such a feature.
>
> By that time, most (including me) have suggested Jasmine as such a 
> framework. But actually I don''t really care which framework would
be
> chosen as it could be easily replaced.
>
> For example, it is pretty clear for me that Konacha has set the proper 
> way of dealing with such kind of tests:
>
> https://github.com/jfirebaugh/konacha
>
> Basically its approach is to provide two useful tasks:
>
> konacha:serve - starts an isolated application sharing the asset 
> pipeline for in-browser test runner;
> konacha:run - suitable for CI, although I''m still not sure what 
> approach to take for implementing such task, so this could be added in 
> the future, after the other task, which approach is more obvious to 
> opt for.
>
> But it has a single issue that is too easy to be fixed - it is not 
> framework agnostic:
>
> https://github.com/jfirebaugh/konacha/issues/37
>
> If Rails provided the idea used by Konacha built in, but providing 
> hooks so that other gems could easily set up the template for their 
> JavaScript runners, this would be a great solution to client-side 
> integrated test solution.
>
> Rails wouldn''t even have to add support for common libraries, like
> Sinon.js or Jasmine. It could include any test runner.
>
> For example, since Rails opts for test/unit assertions style as well 
> as jQuery as default choices, it would make sense to keep with that 
> style by choosing QUnit, which is also developed by the jQuey team and 
> uses the assertions style:
>
> https://github.com/jquery/qunit
> http://docs.jquery.com/QUnit
>
> I wouldn''t use the default QUnit in the same way I don''t
use test/unit
> for my Ruby tests, but it should be trivial to just add a gem composed 
> by one or two files that would enable me to use Jasmine while taking 
> advantage of the assets pipeline.
>
> Of course I can already have something like this working in current 
> Rails, but the approach taken by Konacha seems so straightforward, 
> clean and simple to me that it seems that every runner should take a 
> similar approach basically changing only some settings like the 
> template of the runner as well as the pattern where to look for test 
> files.
>
> It doesn''t make sense for all similar gems to rewrite all the
common
> infrastructure. And it would be great to transmit the idea that 
> client-side code testing is as much important as server-side testing.
>
> Actually chances are that client-side code will be more and more 
> important as time passes. And still, Rails seems to be ignoring that 
> by not providing tests for the CoffeeScript generated assets.
>
> I wasn''t sure about what approach to take at the time I first
proposed
> including any JavaScript testing framework into Rails, but now I''m
> pretty convinced that Konacha''s simple approach is the correct one
to
> take.
>
> We would just need to add some hooks to make it framework-agnostic, 
> and that shouldn''t be hard to do.
>
> Any thoughts about this?
>
> Kind regards,
> Rodrigo.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

As the author of Konacha, let me add my two cents.

I think it would be great if Rails was opinionated about JS testing. I
fully support having the generated Gemfile for a new Rails application
include a JS testing gem -- any gem: konacha, jasmine, jasminerice,
whatever. I''d prefer to have the default be a framework other than
Konacha
to Rails having no opinion about JS testing at all.

However, I don''t really see the value in a framework agnostic base,
either
as a gem or built in to Rails. Honestly, 98% of what I need for Konacha is
provided out of the box by engines and the asset pipeline, and I''d
rather
have complete flexibility in the remaining 2% than save a few lines of code
but be limited by the base. To pick a couple examples of limitations in
rails-sandbox-assets: I want the name of the config root for Konacha to be
''konacha'', not ''sandbox_assets'', and I
don''t want to require
configuration (config.sandbox_assets.template
= ''mocha_chai/runner'') that is redundant to simply adding the
gem to the
Gemfile.

The amazing thing about Rails 3 is how easy it is to add sophisticated
functionality with zero configuration just by adding or changing a gem in
the Gemfile. That''s why so much of the agonizing about Rails''s
opinions is
overwrought. Because the defaults are so easy to change, the important
thing is that Rails *has *a default, not what the default actually is. And
I think the value in having an opinion about JS testing can be entirely
realized by defaulting to one of the existing frameworks.

Cheers,
John


On Thu, May 24, 2012 at 7:07 AM, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com
> wrote:
>  Here is an example of what I was talking about. Framework agnostic and
> easy to extend:
>
> https://github.com/rosenfeld/rails-sandbox-assets
>
> As you can see, adding support for the Jasmine test runner on top of the
> gem above is pretty simple:
>
> https://github.com/rosenfeld/rails_sandbox_jasmine
>
> Any chances of getting something like this built into Rails 4?
>
> Cheers,
> Rodrigo.
>
> Em 23-05-2012 00:05, Rodrigo Rosenfeld Rosas escreveu:
>
> A while ago I started a topic here asking for including any framework for
> testing client-side code built into Rails and integrated to generators as
> well.
>
> Rails 4 would be a great opportunity for including such a feature.
>
> By that time, most (including me) have suggested Jasmine as such a
> framework. But actually I don''t really care which framework would
be chosen
> as it could be easily replaced.
>
> For example, it is pretty clear for me that Konacha has set the proper way
> of dealing with such kind of tests:
>
> https://github.com/jfirebaugh/konacha
>
> Basically its approach is to provide two useful tasks:
>
> konacha:serve - starts an isolated application sharing the asset pipeline
> for in-browser test runner;
> konacha:run - suitable for CI, although I''m still not sure what
approach
> to take for implementing such task, so this could be added in the future,
> after the other task, which approach is more obvious to opt for.
>
> But it has a single issue that is too easy to be fixed - it is not
> framework agnostic:
>
> https://github.com/jfirebaugh/konacha/issues/37
>
> If Rails provided the idea used by Konacha built in, but providing hooks
> so that other gems could easily set up the template for their JavaScript
> runners, this would be a great solution to client-side integrated test
> solution.
>
> Rails wouldn''t even have to add support for common libraries, like
> Sinon.js or Jasmine. It could include any test runner.
>
> For example, since Rails opts for test/unit assertions style as well as
> jQuery as default choices, it would make sense to keep with that style by
> choosing QUnit, which is also developed by the jQuey team and uses the
> assertions style:
>
> https://github.com/jquery/qunit
> http://docs.jquery.com/QUnit
>
> I wouldn''t use the default QUnit in the same way I don''t
use test/unit for
> my Ruby tests, but it should be trivial to just add a gem composed by one
> or two files that would enable me to use Jasmine while taking advantage of
> the assets pipeline.
>
> Of course I can already have something like this working in current Rails,
> but the approach taken by Konacha seems so straightforward, clean and
> simple to me that it seems that every runner should take a similar approach
> basically changing only some settings like the template of the runner as
> well as the pattern where to look for test files.
>
> It doesn''t make sense for all similar gems to rewrite all the
common
> infrastructure. And it would be great to transmit the idea that client-side
> code testing is as much important as server-side testing.
>
> Actually chances are that client-side code will be more and more important
> as time passes. And still, Rails seems to be ignoring that by not providing
> tests for the CoffeeScript generated assets.
>
> I wasn''t sure about what approach to take at the time I first
proposed
> including any JavaScript testing framework into Rails, but now I''m
pretty
> convinced that Konacha''s simple approach is the correct one to
take.
>
> We would just need to add some hooks to make it framework-agnostic, and
> that shouldn''t be hard to do.
>
> Any thoughts about this?
>
> Kind regards,
> Rodrigo.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Hi John, thank you very much for your feedback. I really appreciate very 
much your Konacha gem and I would be actually using it if I didn''t want
to run my specs against IE...

But back to the subject, I''ve just created some examples on how you 
could achieve what you wanted on top of rails-sandbox-assets. Please see 
the commit logs so that you can see how little effort was required.

 From scratch:

https://github.com/rosenfeld/konacha_like

By reusing rails_sandbox_mocha_chai gem:

https://github.com/rosenfeld/konacha_reuse

The reason I don''t set the default template in any of my example gems
is
to allow you to have a mixed spec-runners environment:

https://github.com/rosenfeld/mixed_test_runners

Can you see how having some base support would help a lot?

But more importantly, you don''t even need any extra gem if your 
application depends on rails-sandbox-assets.

Just follow the example in konacha_like, but place your assets and spec 
runner view directly into your application.

Anyway, I''ve just opened the discussion for the usefulness of having a 
basic support for helping to create JavaScript tests in Rails applications.

Also, I''m not against including any available (or even custom)
test/spec
runner with a new Rails application by default.

Don''t you think the examples above would justify such support?

Thanks for your feedback,
Rodrigo.

Em 24-05-2012 23:05, John Firebaugh escreveu:
> As the author of Konacha, let me add my two cents.
>
> I think it would be great if Rails was opinionated about JS testing. I 
> fully support having the generated Gemfile for a new Rails application 
> include a JS testing gem -- any gem: konacha, jasmine, jasminerice, 
> whatever. I''d prefer to have the default be a framework other than
> Konacha to Rails having no opinion about JS testing at all.
>
> However, I don''t really see the value in a framework agnostic
base,
> either as a gem or built in to Rails. Honestly, 98% of what I need for 
> Konacha is provided out of the box by engines and the asset pipeline, 
> and I''d rather have complete flexibility in the remaining 2% than
save
> a few lines of code but be limited by the base. To pick a couple 
> examples of limitations in rails-sandbox-assets: I want the name of 
> the config root for Konacha to be ''konacha'', not
''sandbox_assets'', and
> I don''t want to require configuration
(config.sandbox_assets.template
> = ''mocha_chai/runner'') that is redundant to simply adding
the gem to
> the Gemfile.
>
> The amazing thing about Rails 3 is how easy it is to add sophisticated 
> functionality with zero configuration just by adding or changing a gem 
> in the Gemfile. That''s why so much of the agonizing about
Rails''s
> opinions is overwrought. Because the defaults are so easy to change, 
> the important thing is that Rails /has /a default, not what the 
> default actually is. And I think the value in having an opinion about 
> JS testing can be entirely realized by defaulting to one of the 
> existing frameworks.
>
> Cheers,
> John
>
>
> On Thu, May 24, 2012 at 7:07 AM, Rodrigo Rosenfeld Rosas 
> <rr.rosas@gmail.com <mailto:rr.rosas@gmail.com>> wrote:
>
>     Here is an example of what I was talking about. Framework agnostic
>     and easy to extend:
>
>     https://github.com/rosenfeld/rails-sandbox-assets
>
>     As you can see, adding support for the Jasmine test runner on top
>     of the gem above is pretty simple:
>
>     https://github.com/rosenfeld/rails_sandbox_jasmine
>
>     Any chances of getting something like this built into Rails 4?
>
>     Cheers,
>     Rodrigo.
>
>     Em 23-05-2012 00:05, Rodrigo Rosenfeld Rosas escreveu:
>>     A while ago I started a topic here asking for including any
>>     framework for testing client-side code built into Rails and
>>     integrated to generators as well.
>>
>>     Rails 4 would be a great opportunity for including such a feature.
>>
>>     By that time, most (including me) have suggested Jasmine as such
>>     a framework. But actually I don''t really care which
framework
>>     would be chosen as it could be easily replaced.
>>
>>     For example, it is pretty clear for me that Konacha has set the
>>     proper way of dealing with such kind of tests:
>>
>>     https://github.com/jfirebaugh/konacha
>>
>>     Basically its approach is to provide two useful tasks:
>>
>>     konacha:serve - starts an isolated application sharing the asset
>>     pipeline for in-browser test runner;
>>     konacha:run - suitable for CI, although I''m still not sure
what
>>     approach to take for implementing such task, so this could be
>>     added in the future, after the other task, which approach is more
>>     obvious to opt for.
>>
>>     But it has a single issue that is too easy to be fixed - it is
>>     not framework agnostic:
>>
>>     https://github.com/jfirebaugh/konacha/issues/37
>>
>>     If Rails provided the idea used by Konacha built in, but
>>     providing hooks so that other gems could easily set up the
>>     template for their JavaScript runners, this would be a great
>>     solution to client-side integrated test solution.
>>
>>     Rails wouldn''t even have to add support for common
libraries,
>>     like Sinon.js or Jasmine. It could include any test runner.
>>
>>     For example, since Rails opts for test/unit assertions style as
>>     well as jQuery as default choices, it would make sense to keep
>>     with that style by choosing QUnit, which is also developed by the
>>     jQuey team and uses the assertions style:
>>
>>     https://github.com/jquery/qunit
>>     http://docs.jquery.com/QUnit
>>
>>     I wouldn''t use the default QUnit in the same way I
don''t use
>>     test/unit for my Ruby tests, but it should be trivial to just add
>>     a gem composed by one or two files that would enable me to use
>>     Jasmine while taking advantage of the assets pipeline.
>>
>>     Of course I can already have something like this working in
>>     current Rails, but the approach taken by Konacha seems so
>>     straightforward, clean and simple to me that it seems that every
>>     runner should take a similar approach basically changing only
>>     some settings like the template of the runner as well as the
>>     pattern where to look for test files.
>>
>>     It doesn''t make sense for all similar gems to rewrite all
the
>>     common infrastructure. And it would be great to transmit the idea
>>     that client-side code testing is as much important as server-side
>>     testing.
>>
>>     Actually chances are that client-side code will be more and more
>>     important as time passes. And still, Rails seems to be ignoring
>>     that by not providing tests for the CoffeeScript generated assets.
>>
>>     I wasn''t sure about what approach to take at the time I
first
>>     proposed including any JavaScript testing framework into Rails,
>>     but now I''m pretty convinced that Konacha''s
simple approach is
>>     the correct one to take.
>>
>>     We would just need to add some hooks to make it
>>     framework-agnostic, and that shouldn''t be hard to do.
>>
>>     Any thoughts about this?
>>
>>     Kind regards,
>>     Rodrigo.
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

I started to use konacha on my rails applications and it feels so right.

Would be great to have something like konacha integrated on rails 
applications or at least as default suggestion on Gemfile like happens with 
coffe-script.

On Friday, May 25, 2012 12:58:44 AM UTC-3, Rodrigo Rosenfeld Rosas
wrote:
>
>  Hi John, thank you very much for your feedback. I really appreciate very 
> much your Konacha gem and I would be actually using it if I didn''t
want to
> run my specs against IE...
>
> But back to the subject, I''ve just created some examples on how
you could
> achieve what you wanted on top of rails-sandbox-assets. Please see the 
> commit logs so that you can see how little effort was required.
>
> From scratch:
>
> https://github.com/rosenfeld/konacha_like
>
> By reusing rails_sandbox_mocha_chai gem:
>
> https://github.com/rosenfeld/konacha_reuse
>
> The reason I don''t set the default template in any of my example
gems is
> to allow you to have a mixed spec-runners environment:
>
> https://github.com/rosenfeld/mixed_test_runners
>
> Can you see how having some base support would help a lot?
>
> But more importantly, you don''t even need any extra gem if your 
> application depends on rails-sandbox-assets.
>
> Just follow the example in konacha_like, but place your assets and spec 
> runner view directly into your application.
>
> Anyway, I''ve just opened the discussion for the usefulness of
having a
> basic support for helping to create JavaScript tests in Rails applications.
>
> Also, I''m not against including any available (or even custom)
test/spec
> runner with a new Rails application by default.
>
> Don''t you think the examples above would justify such support?
>
> Thanks for your feedback,
> Rodrigo.
>
> Em 24-05-2012 23:05, John Firebaugh escreveu: 
>
> As the author of Konacha, let me add my two cents. 
>
>  I think it would be great if Rails was opinionated about JS testing. I 
> fully support having the generated Gemfile for a new Rails application 
> include a JS testing gem -- any gem: konacha, jasmine, jasminerice, 
> whatever. I''d prefer to have the default be a framework other than
Konacha
> to Rails having no opinion about JS testing at all.
>
>  However, I don''t really see the value in a framework agnostic
base,
> either as a gem or built in to Rails. Honestly, 98% of what I need for 
> Konacha is provided out of the box by engines and the asset pipeline, and 
> I''d rather have complete flexibility in the remaining 2% than save
a few
> lines of code but be limited by the base. To pick a couple examples of 
> limitations in rails-sandbox-assets: I want the name of the config root for
> Konacha to be ''konacha'', not
''sandbox_assets'', and I don''t want to require
> configuration (config.sandbox_assets.template =
''mocha_chai/runner'') that
> is redundant to simply adding the gem to the Gemfile.
>
>  The amazing thing about Rails 3 is how easy it is to add sophisticated 
> functionality with zero configuration just by adding or changing a gem in 
> the Gemfile. That''s why so much of the agonizing about
Rails''s opinions is
> overwrought. Because the defaults are so easy to change, the important 
> thing is that Rails *has *a default, not what the default actually is. 
> And I think the value in having an opinion about JS testing can be entirely
> realized by defaulting to one of the existing frameworks.
>
>  Cheers,
> John
>
>  
> On Thu, May 24, 2012 at 7:07 AM, Rodrigo Rosenfeld Rosas <
> rr.rosas@gmail.com> wrote:
>
>>  Here is an example of what I was talking about. Framework agnostic and
>> easy to extend:
>>
>> https://github.com/rosenfeld/rails-sandbox-assets
>>
>> As you can see, adding support for the Jasmine test runner on top of
the
>> gem above is pretty simple:
>>
>> https://github.com/rosenfeld/rails_sandbox_jasmine
>>
>> Any chances of getting something like this built into Rails 4?
>>
>> Cheers,
>> Rodrigo.
>>
>> Em 23-05-2012 00:05, Rodrigo Rosenfeld Rosas escreveu: 
>>  
>> A while ago I started a topic here asking for including any framework
for
>> testing client-side code built into Rails and integrated to generators
as
>> well.
>>
>> Rails 4 would be a great opportunity for including such a feature.
>>
>> By that time, most (including me) have suggested Jasmine as such a 
>> framework. But actually I don''t really care which framework
would be chosen
>> as it could be easily replaced.
>>
>> For example, it is pretty clear for me that Konacha has set the proper 
>> way of dealing with such kind of tests:
>>
>> https://github.com/jfirebaugh/konacha
>>
>> Basically its approach is to provide two useful tasks:
>>
>> konacha:serve - starts an isolated application sharing the asset
pipeline
>> for in-browser test runner;
>> konacha:run - suitable for CI, although I''m still not sure
what approach
>> to take for implementing such task, so this could be added in the
future,
>> after the other task, which approach is more obvious to opt for.
>>
>> But it has a single issue that is too easy to be fixed - it is not 
>> framework agnostic:
>>
>> https://github.com/jfirebaugh/konacha/issues/37
>>
>> If Rails provided the idea used by Konacha built in, but providing
hooks
>> so that other gems could easily set up the template for their
JavaScript
>> runners, this would be a great solution to client-side integrated test 
>> solution.
>>
>> Rails wouldn''t even have to add support for common libraries,
like
>> Sinon.js or Jasmine. It could include any test runner.
>>
>> For example, since Rails opts for test/unit assertions style as well as
>> jQuery as default choices, it would make sense to keep with that style
by
>> choosing QUnit, which is also developed by the jQuey team and uses the 
>> assertions style:
>>
>> https://github.com/jquery/qunit
>> http://docs.jquery.com/QUnit
>>
>> I wouldn''t use the default QUnit in the same way I
don''t use test/unit
>> for my Ruby tests, but it should be trivial to just add a gem composed
by
>> one or two files that would enable me to use Jasmine while taking
advantage
>> of the assets pipeline.
>>
>> Of course I can already have something like this working in current 
>> Rails, but the approach taken by Konacha seems so straightforward,
clean
>> and simple to me that it seems that every runner should take a similar 
>> approach basically changing only some settings like the template of the
>> runner as well as the pattern where to look for test files.
>>
>> It doesn''t make sense for all similar gems to rewrite all the
common
>> infrastructure. And it would be great to transmit the idea that
client-side
>> code testing is as much important as server-side testing.
>>
>> Actually chances are that client-side code will be more and more 
>> important as time passes. And still, Rails seems to be ignoring that by
not
>> providing tests for the CoffeeScript generated assets.
>>
>> I wasn''t sure about what approach to take at the time I first
proposed
>> including any JavaScript testing framework into Rails, but now
I''m pretty
>> convinced that Konacha''s simple approach is the correct one to
take.
>>
>> We would just need to add some hooks to make it framework-agnostic, and
>> that shouldn''t be hard to do.
>>
>> Any thoughts about this?
>>
>> Kind regards,
>> Rodrigo.
>>
>>     
>  
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/dkITaffvtWkJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.