Javascript is now a first-class code citizen - Really?!

[Rodrigo Rosenfeld Rosas]

Hi guys,

While reading the 3.1 release notes in Rails Guides, I've stumbled across this phrase:

"The major change in Rails 3.1 is the Assets Pipeline. It makes CSS and JavaScript first-class code citizens and enables proper organization, including use in plugins and engines."

Then, I started thinking that it might not be really true. I guess, that it is time for Rails to adopt a default testing framework for Javascript (both unit and integration).

There should also exist a Javascript generator that would generate the empty test file too. It would also be interesting if we could generate views with "--include-javascript", which would include a new file, like, for instance, with jQuery:

jQuery(function($){
    // place your code here.
})

Is there already something like this in Rails? I don't remember reading anything about Javascript TDD natively with Rails.

It seems like Capybara has became the defacto solution for this kind of test. Maybe it could be the default Javascript test framework (using webkit by default, maybe).

Any thoughts?

Cheers,

Rodrigo.

[Everton Moreth]

A standard javascript testing library would be awesome.

Today we struggle with lots of different aproaches to test javascript, using only selenium, capybara/selenium, cucumber/capybara/selenium, jasmine, etc... And other non Rails techniques. It would be great if we could rely and focus on a single framework to develop to and help.

+1

Everton Moreth

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

[Wael Nasreddine]

+1 too, jasmine for unit testing and capybara for integration tests

Regards,

Wael

-- 

Wael Nasreddine

Sent from my iPhone

[Nicolás Sanguinetti]

On Wed, Aug 31, 2011 at 3:10 PM, Wael Nasreddine
<wael.na...@gmail.com> wrote:
> +1 too, jasmine for unit testing and capybara for integration tests

Wellllll… make Jasmine optional and I'm a happy camper :)

[Wael Nasreddine]

On Aug 31, 2011, at 20:14, Nicolás Sanguinetti
<h...@nicolassanguinetti.info> wrote:

> On Wed, Aug 31, 2011 at 3:10 PM, Wael Nasreddine
> <wael.na...@gmail.com> wrote:
>> +1 too, jasmine for unit testing and capybara for integration tests
>
> Wellllll… make Jasmine optional and I'm a happy camper :)

From our experience with all rails features, rspec, test-unit, haml,
erb etc.. I don't think anything would be mandatory, but instead
through generators and we choose whatever we want... Anyway Jasmine is
my preference for unit testing and what i said is mere suggestion :)

Wael

[Andrés Mejía]

I like Jasmine too.

[Ryan Bigg]

I think due to the large number of testing frameworks out there for JavaScript, we should leave this in the developer's hands and not make it a part of the Rails core.

[Rodrigo Rosenfeld Rosas]

When you do that, it would be similar to not adding tests on generators or not providing Coffeescript or SASS support in a default new Rails application.

I doubt Coffeescript would be largely used if not included in Rails by default. I prefer Rspec over Test/Unit but I don't see any problems with Rails shipping the last by default. And there are other test units available too, but Rails chose one anyway... And I agree with that.

The problem is that the message that Rails gives to developers is that Javascript (or Coffeescript) doesn't need to be tested or it would be generated by the generators.

I think that lots of developers would worry more about testing Javascript and organizing their files if Rails guided them how to do that through examples in the generated code.

We don't need to take the best shot now. Anything chosen as default is good as far as we can change the defaults. We would probably have a new book on testing Javascript with Rails showing up soon.

The only dedicated book I know of is the book from my friend at Gitorious AS, Christian Johansen:

http://www.amazon.com/Test-Driven-JavaScript-Development-ebook/dp/B004519O02/ref=tmm_kin_title_0?ie=UTF8&m=AGFP5ZROMRZFO

Did you get my point?

[Allen Madsen]

What Rodrigo said.

+1 for jasmine

Allen Madsen
http://www.allenmadsen.com

[Michael Breen]

On Aug 31, 2011, at 6:11 PM, Rodrigo Rosenfeld Rosas wrote:

When you do that, it would be similar to not adding tests on generators or not providing Coffeescript or SASS support in a default new Rails application.

I doubt Coffeescript would be largely used if not included in Rails by default. I prefer Rspec over Test/Unit but I don't see any problems with Rails shipping the last by default. And there are other test units available too, but Rails chose one anyway... And I agree with that.

Rails doesn't really ship with any testing framework. It defaults to what's in Ruby core, which is Test/Unit  in 1.8 and MiniTest in 1.9.

The problem is that the message that Rails gives to developers is that Javascript (or Coffeescript) doesn't need to be tested or it would be generated by the generators.

I think that lots of developers would worry more about testing Javascript and organizing their files if Rails guided them how to do that through examples in the generated code.

We don't need to take the best shot now. Anything chosen as default is good as far as we can change the defaults. We would probably have a new book on testing Javascript with Rails showing up soon.

The only dedicated book I know of is the book from my friend at Gitorious AS, Christian Johansen:

http://www.amazon.com/Test-Driven-JavaScript-Development-ebook/dp/B004519O02/ref=tmm_kin_title_0?ie=UTF8&m=AGFP5ZROMRZFO

Did you get my point?


Em 31-08-2011 18:56, Ryan Bigg escreveu:

I think due to the large number of testing frameworks out there for JavaScript, we should leave this in the developer's hands and not make it a part of the Rails core.

On 31/08/2011, at 23:06, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> wrote:

Hi guys,

While reading the 3.1 release notes in Rails Guides, I've stumbled across this phrase:

"The major change in Rails 3.1 is the Assets Pipeline. It makes CSS and JavaScript first-class code citizens and enables proper organization, including use in plugins and engines."

Then, I started thinking that it might not be really true. I guess, that it is time for Rails to adopt a default testing framework for Javascript (both unit and integration).

There should also exist a Javascript generator that would generate the empty test file too. It would also be interesting if we could generate views with "--include-javascript", which would include a new file, like, for instance, with jQuery:

jQuery(function($){
    // place your code here.
})

Is there already something like this in Rails? I don't remember reading anything about Javascript TDD natively with Rails.

It seems like Capybara has became the defacto solution for this kind of test. Maybe it could be the default Javascript test framework (using webkit by default, maybe).

Any thoughts?

Cheers,

Rodrigo.

[Chad Woolley]

On Thu, Sep 1, 2011 at 6:40 AM, Michael Breen <har...@gmail.com> wrote:
> Rails doesn't really ship with any testing framework. It defaults to what's
> in Ruby core, which is Test/Unit  in 1.8 and MiniTest in 1.9.

* Rails ships with Ruby test generators (because testing is good)
* Rails ships with Javascript/Coffeescript generators
* There's no Javascript testing framework in Ruby core, nor Rails.
(testing is only good for Ruby code?)

One of Rails' many opinionated innovations as a framework was that
testing is good, everyone should do it by default, so test code is
included/generated by the framework. I believe it should be just as
opinionated about Javascript testing.

As Rodrigo said, it doesn't matter which framework is used (although
Jasmine is nice and iterates/improves upon several earlier tools). The
important thing is to send the message that Javascript can and should
be tested.

-- Chad

[Everton Moreth]

I agree with Rodrigo, it should be optional, but when the Rails Community takes its choice in supporting anything, it gets attention, people start to use it, and even the framework itself gets better.

Also, we really should ease the new developers life in pointing which framework to use when starting with rails and choosing the test frameworks.

Everton

[Chad Woolley]

On Thu, Sep 1, 2011 at 7:46 AM, Everton Moreth <everton...@gmail.com> wrote:
> I agree with Rodrigo, it should be optional, but when the Rails Community
> takes its choice in supporting anything, it gets attention, people start to
> use it, and even the framework itself gets better.
>
> Also, we really should ease the new developers life in pointing which
> framework to use when starting with rails and choosing the test frameworks.

A few relevant links:

http://pivotallabs.com/users/mgehard/blog/articles/1683-using-jasmine-to-test-coffeescript-in-a-rails-3-1-app
http://pivotallabs.com/users/jdean/blog/articles/1778
http://gilesbowkett.blogspot.com/2011/08/tdd-in-javascript-no-excuses.html

[Jonas Nicklas]

Definitely +1 for Jasmine

It's easily the best test framework for JavaScript. I wrote a wrapper
around it called Evergreen, which has gained a little traction. You
should check it out for inspiration I think, since it does a lot of
things very differently than most other similar libraries. I think
it's far superior to e.g. the jasmine gem.

It doesn't yet work with the asset pipeline, since I've been holding
off for the official Rails 3.1 release. So asset pipeline support will
be there soon.

I'm not really campaigning for this to be included in Rails, honestly
I think I prefer it as a separate library, but if you do go down that
route, at least check out the concepts around which Evergreen is
built. I think it has a much better out-of-the-box experience than
pretty much anything else out there.

https://github.com/jnicklas/evergreen

/Jonas

[Jonathan Lozinski]

+1 for evergreen

Sent from my iPhone

[Sidu Ponnappa]

> One of Rails' many opinionated innovations as a framework was that
> testing is good, everyone should do it by default, so test code is
> included/generated by the framework. I believe it should be just as
> opinionated about Javascript testing.

+1 to TDD for js, and +1 to Jasmine - I've been test driving js for a
few years now and Jasmine is a nice tool, probably the best I've used.

It's high time folks were encouraged to write real unit tests for js
rather than use Selenium/Sahi/etc.

Best,
Sidu Ponnappa.
http://c42.in
http://blog.sidu.in

[Trek Glowacki]

I think the appropriate question to ask is "of Rails developers unit testing their javascript, who is *not* using Jasmine"

I definitely get the impression that 

* most people are not unit testing their javascript application code, instead relying on integration tests to catch errors

* among those who do, jasmine is the most frequently used.

I happen to use Jasmine, but I'm not particuarly wild about it. I'd be interested in what over people use, but I suspect Jasmine is it.

Although there are a *lot* of javascript testing libraries, there isn't much consensus among javascripters which one(s) to use. As a result, they all suffer from the lack of support and tooling. Each library seems to be missing key features. Major framework support of one of them (Jasmine or not) would hopefully catapult one to the forefront.

+1 for any damn thing.

-Trek

[Michael Koziarski]

On Friday, 2 September 2011 at 9:23 AM, Trek Glowacki wrote:

I think the appropriate question to ask is "of Rails developers unit testing their javascript, who is *not* using Jasmine"

I definitely get the impression that 

* most people are not unit testing their javascript application code, instead relying on integration tests to catch errors

* among those who do, jasmine is the most frequently used.

I happen to use Jasmine, but I'm not particuarly wild about it. I'd be interested in what over people use, but I suspect Jasmine is it.

Although there are a *lot* of javascript testing libraries, there isn't much consensus among javascripters which one(s) to use. As a result, they all suffer from the lack of support and tooling. Each library seems to be missing key features. Major framework support of one of them (Jasmine or not) would hopefully catapult one to the forefront.

+1 for any damn thing.

Until there's a clear winner I don't think there's much point us 'picking a winner'.  As you say, being included in rails will likely provide a lot of momentum to whatever was picked and I'd prefer that that momentum was added to something which had already proven it was head and shoulders above the rest. There are sufficient hooks for gems to implement the generators and rake tasks as required, so i think we don't need to hastily include the flavor of the month when it's still changing so regularly.

 

Remember, it took us till 3.1 to switch to jQuery by default.  Some caution in a project of our size is warranted.  Once everyone in the JS testing camp is pushing the same tech, we can see what, if anything, we need to bake into rails itself.

--

Cheers,

Koz

[Steve Schwartz]

We use qunit to test jquery-ujs, for what its worth.

-Steve Schwartz (@jangosteve)

[Rodrigo Rosenfeld Rosas]

Hi Koz,

I'm not sure if that is the best approach. Choosing a default is not about choosing the winner. Is Test/Unit the winner over Rspec? Different people will have different opinions about the winner. But they don't complain about Rspec not being the default one. Nor Rspec lost its momentum.

People currently using Jasmine will probably still use Jasmine if another default is chosen.

This is about making a point about the importance of Javascript testing in web applications to Rails developers and make it easy for them to write their tests without needing to reading about lots of Javascript test frameworks, picking one and start to use it.

Most will be too lazy for that and won't write any Javascript test at all. Choosing a default will increase the chances they are going to test their JS while those who like to search for alternatives will continue to look at other approaches. I wouldn't say the Rspec community is small because it is not the default framework. It could be bigger if it was the default, but it is still big not being the default one.

Regarding the "clean winner", I've only heard about Jasmine in this discussion, except for 2 votes for evergreen. And I think all of them will be happy with either is chosen.

I just think that it is a bit strange to deliver a framework that will promote, by default, TDD for Ruby and BDD for Javascript... It would be more consistent if the default JS test library used assertions too instead of specs. Although I prefer evergreen or Jasmine, maybe something like SinonJS would be more aligned to Test/Unit:

http://sinonjs.org/

Regarding jQuery, I don't really know why it took that long for it becoming the default. It didn't need to.

It shouldn't be that complicated for changing the defaults each major release of Rails...

Whenever a better alternative comes up, why shouldn't us adopt as default?

That's the main difference between the Ruby and the other communities in my opinion... We're not afraid of changes... At least, not me.

Cheers,

Rodrigo.

[Mike Breen]

On Sep 1, 10:30 am, Chad Woolley <thewoolley...@gmail.com> wrote:

> On Thu, Sep 1, 2011 at 6:40 AM, Michael Breen <hard...@gmail.com> wrote:
> > Rails doesn't really ship with any testing framework. It defaults to what's
> > in Ruby core, which is Test/Unit  in 1.8 and MiniTest in 1.9.
>
> * Rails ships with Ruby test generators (because testing is good)
> * Rails ships with Javascript/Coffeescript generators
> * There's no Javascript testing framework in Ruby core, nor Rails.
> (testing is only good for Ruby code?)

I wasn't trying to say that Rails shouldn't encourage Javascript
testing. But the fact that Rails does not ship a testing framework
and, out of the box, encourages you to use the testing framework that
is already on your machine should be noted. I can't recall ever seeing
3000+ word blog posts on getting Test/Unit to work with Rails as I
have for other testing frameworks.

Ruby core may never include a Javascript testing framework but maybe
this shouldn't be decided by a bunch of +1's on a thread right now.
Since some of these features/tools are new to Rails maybe the best
thing to do (as others have noted) is to see how the JS testing
frameworks adapt and evolve before forming an opinion?

[Simon de Boer]

+1 any damn thing.

+1 to be accepting of change down the road.

We won't really know and understand the impact of having a default JS
test apparatus until its put in there and the feedback comes back in
from production people over the course of a year or two.

[Paul]

I agree with Rodrigo. It's not about choosing a winner, but rather
encouraging JS testing and helping people get started.

+1