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 < > [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 view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/dkITaffvtWkJ. 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.
