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 <[email protected] > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
