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] <mailto:[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.
