Rails core - Aug 2011 - Javascript is now a first-class code citizen - Really?!

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

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

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

On Wed, Aug 31, 2011 at 10:06 AM, Rodrigo Rosenfeld Rosas <
rr.rosas@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.
>
>  --
> 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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

Regards,
Wael

-- 
Wael Nasreddine
Sent from my iPhone

On Aug 31, 2011, at 19:46, Everton Moreth <everton.moreth@gmail.com>
wrote:

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

On Wed, Aug 31, 2011 at 10:06 AM, Rodrigo Rosenfeld Rosas <
rr.rosas@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.
>
>  --
> 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On Wed, Aug 31, 2011 at 3:10 PM, Wael Nasreddine
<wael.nasreddine@gmail.com> wrote:
> +1 too, jasmine for unit testing and capybara for integration tests
Wellllll… make Jasmine optional and I''m a happy camper :)
> Regards,
> Wael
>
> --
> Wael Nasreddine
> Sent from my iPhone
> On Aug 31, 2011, at 19:46, Everton Moreth <everton.moreth@gmail.com>
wrote:
>
> 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
>
> On Wed, Aug 31, 2011 at 10:06 AM, Rodrigo Rosenfeld Rosas
> <rr.rosas@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.
>>
>> --
>> 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 rubyonrails-core@googlegroups.com.
>> To unsubscribe from this group, send email to
>> rubyonrails-core+unsubscribe@googlegroups.com.
>> 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On Aug 31, 2011, at 20:14, Nicolás Sanguinetti
<hi@nicolassanguinetti.info> wrote:
> On Wed, Aug 31, 2011 at 3:10 PM, Wael Nasreddine
> <wael.nasreddine@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
>
>> Regards,
>> Wael
>>
>> --
>> Wael Nasreddine
>> Sent from my iPhone
>> On Aug 31, 2011, at 19:46, Everton Moreth
<everton.moreth@gmail.com> wrote:
>>
>> 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
>>
>> On Wed, Aug 31, 2011 at 10:06 AM, Rodrigo Rosenfeld Rosas
>> <rr.rosas@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.
>>>
>>> --
>>> 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
rubyonrails-core@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> rubyonrails-core+unsubscribe@googlegroups.com.
>>> 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 rubyonrails-core@googlegroups.com.
>> To unsubscribe from this group, send email to
>> rubyonrails-core+unsubscribe@googlegroups.com.
>> 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 rubyonrails-core@googlegroups.com.
>> To unsubscribe from this group, send email to
>> rubyonrails-core+unsubscribe@googlegroups.com.
>> 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

I like Jasmine too.

On Wed, Aug 31, 2011 at 1:45 PM, Wael Nasreddine
<wael.nasreddine@gmail.com>wrote:
> On Aug 31, 2011, at 20:14, Nicolás Sanguinetti
> <hi@nicolassanguinetti.info> wrote:
>
> > On Wed, Aug 31, 2011 at 3:10 PM, Wael Nasreddine
> > <wael.nasreddine@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
>
> >
> >> Regards,
> >> Wael
> >>
> >> --
> >> Wael Nasreddine
> >> Sent from my iPhone
> >> On Aug 31, 2011, at 19:46, Everton Moreth
<everton.moreth@gmail.com>
> wrote:
> >>
> >> 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
> >>
> >> On Wed, Aug 31, 2011 at 10:06 AM, Rodrigo Rosenfeld Rosas
> >> <rr.rosas@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.
> >>>
> >>> --
> >>> 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
rubyonrails-core@googlegroups.com
> .
> >>> To unsubscribe from this group, send email to
> >>> rubyonrails-core+unsubscribe@googlegroups.com.
> >>> 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
rubyonrails-core@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> rubyonrails-core+unsubscribe@googlegroups.com.
> >> 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
rubyonrails-core@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> rubyonrails-core+unsubscribe@googlegroups.com.
> >> 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
rubyonrails-core@googlegroups.com.
> > To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> > 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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

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

What Rodrigo said.

+1 for jasmine

Allen Madsen
http://www.allenmadsen.com


On Wed, Aug 31, 2011 at 6:11 PM, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com
> 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.
>
> 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.rosas@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.
>
>
>  --
> 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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

On Thu, Sep 1, 2011 at 6:40 AM, Michael Breen <hardbap@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

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

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

On Thu, Sep 1, 2011 at 11:30 AM, Chad Woolley
<thewoolleyman@gmail.com>wrote:
> On Thu, Sep 1, 2011 at 6:40 AM, Michael Breen <hardbap@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
>
> --
> 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On Thu, Sep 1, 2011 at 7:46 AM, Everton Moreth <everton.moreth@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

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

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

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

+1 for evergreen

Sent from my iPhone

On 1 Sep 2011, at 16:45, Jonas Nicklas <jonas.nicklas@gmail.com> wrote:
> 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
>
> --
> 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

> 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


On 1 September 2011 20:00, Chad Woolley <thewoolleyman@gmail.com>
wrote:
> 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.
>
-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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 

On Thursday, September 1, 2011 at 11:44 AM, Jonas Nicklas wrote:
> 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
> 
> -- 
> 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 rubyonrails-core@googlegroups.com
(mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
(mailto:rubyonrails-core+unsubscribe@googlegroups.com).
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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

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

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

-Steve Schwartz (@jangosteve)

On Sep 1, 2011, at 5:40 PM, Michael Koziarski wrote:
> 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
>
>
> -- 
> 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 rubyonrails- 
> core@googlegroups.com.
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
> .
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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.

Em 01-09-2011 18:40, Michael Koziarski escreveu:
> 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
>
-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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?

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

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


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

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

+1

On Sep 2, 7:03 am, Simon de Boer <sdeb...@ingamer.com>
wrote:
> +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.
-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.