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

rubyonrails-core
1

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.
2

+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.

3

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.
4

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

5

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.
6

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.