thr3ads.net - Rails - testing [May 2007]

If this information is useful, please help other people find it:
Share via:

gino

2007-May-14 08:59 UTC

testing

what''s the difference beween testin the rails way, or just using the
the
browser?
I don''t like testing, I don''t know how, and it will take time
for me to
learn it
if using the browser is the same as testing? then I''m not intrested in
testing with the framework
if it fails in the browser, it will fail in the test
if it fails in the test, it will fail in the browser
then what''s the difference ?
What I care more is not to fail in the browser, because that''s what
it''s
for in the first place, to be browsed
if you can tall me a reason for testing, I will appreciate, that way
I''ll have a reason, and learn more happily
I am using only development for now, maybe in production is diffrent

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Phlip

2007-May-14 09:32 UTC

head link

Re: testing

gino wrote:
> what''s the difference beween testin the rails way, or just using
the the
> browser?
The same amount of testing that could take 5 seconds in automate tests, 
could take 5 days in manual tests.

If your testing cycle is faster, you can run the tests more often. Run them 
after every few code edits, and always try to predict their outcome.

That lets you know instantly when you make most mistakes. Not days later. 
And that lets you go faster, and take more risks.

http://www.faisal.com/docs/ror-list-faq.html

"Why do I need to write all these tests?

"You don''t need to, but it''s probably a good idea if you
want your code to
actually work. There is a technical answer and a philosophical reasons to 
test with Ruby (and, by implication, Rails).

"The technical answer is that Ruby, like all dynamic languages, does more
at
runtime and less at compile time. Accordingly, the compiler won''t catch
a
lot of the sorts of things that Java and C#''s compilers would. However,
a
test suite that exercises much of your code will tend to catch those 
problems.

"The philosophical answer is that the Rails community tends to favor Agile 
methods of software development, and Agile methods tend to favor test-heavy 
(often test-first or test driven) programming practices due to their 
flexibility.

"In any case, Rails comes with a built in testing framework, and Rails 
developers tend to use the framework heavily."
> I don''t like testing, I don''t know how, and it will take
time for me to
> learn it
> if using the browser is the same as testing? then I''m not
intrested in
> testing with the framework
I don''t like debugging. I don''t like having a bug, and not
knowing even what
module to look in to find it. I don''t like writing
''p'' statements, then
watching the server transcript while poking around the user interface 
looking for the bug. With tests, the odds of that kind of debugging goes way 
down.

This requires you learn to write the tests. Unit tests are very important, 
and one of the hardest situations to test is a website. Some frameworks for 
much simpler programs don''t have any unit test framework. Rails is
unique in
the programming industry for offering one of the best test frameworks in the 
world, and making it completely cover website testing.

This presents a challenge to a neophyte, and I don''t really blame you
for
finding it daunting. To learn testing for websites, even under Rails, you 
must work and work to figure out how to write those test cases, and then you 
must make them simple and flexible. Rails will help you, even as the website 
technology itself hinders you!
> if it fails in the browser, it will fail in the test
> if it fails in the test, it will fail in the browser
> then what''s the difference ?
It fails in the test automatically, instantly.

It fails in the browser only after you click and click to force the tested 
situation. Even then, you might not notice the bug, because it might be one 
wrong variable in the database, not a big obvious problem on a web page.

Next, if you add a new feature X, it might break an old feature Y. Under 
manual testing, you might only think to try X. Under automated testing, the 
tests you wrote for Y will still try to run, and they might report the 
problem.
> What I care more is not to fail in the browser, because that''s
what it''s
> for in the first place, to be browsed
> if you can tall me a reason for testing, I will appreciate, that way
> I''ll have a reason, and learn more happily
Here''s how it works, after you learn it. I write a test for a
super-simple
thing, such as submit a form:

  def test_my_form
     get :my_page
     submit_form ''my_form''
  end

I run that and get it to fail. Then I add <form
id=''my_form'' ...> to the
target page (usually inside a form_tag). Then the test passes.

Then I repeat for the next feature. To add an edit field to my form, I make 
the test query the button''s existence:

  def test_my_form
     login_as :franklyn
     get :my_page
     submit_form ''my_form'' do
        assert_equal ''franklyn'',
form[''my_edit_field''], value
     end
  end

Then that fails, and I write the code to pass the test.

The result is I write each simple feature twice, once as a test and again as 
code. Each feature is simple, so this does not slow me down.

However, I rarely have to run the actual website now! That allows me to 
spend all my time adding features, and almost no time manually running the 
browser just to look at each feature I add. Watching each test pass is the 
same as running the browser and looking at the feature. The tests become my 
view into what the website is doing. If I am curious about a feature, I can 
write another test for it, and I always make sure that writing more tests is 
easy.
> I am using only development for now, maybe in production is diffrent
The best way to develop is with tests, early and often. If you delay such 
things until production, you will create a lot of nasty surprises. Writing 
tests at the same time as writing code is very easy, and adding tests after 
the code is extremely hard. Now is the time to develop good work habits.

Rails, and testing, will put anyone into the top 1% of all programmers for 
speed and efficiency. Many programmers, including old ones who think they 
know everything, still refuse to write tests. The wild success of the Rails 
platform shows how productive they can be.

-- 
  Phlip
  http://www.oreilly.com/catalog/9780596510657/
  "Test Driven Ajax (on Rails)"
  assert_xpath, assert_javascript, & assert_ajax 

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

njmacinnes-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

2007-May-14 12:56 UTC

head link

Re: testing

Wow, that''s a very comprehensive response. I''d just like to
add that it took
me a while to get into rails testing. I used to do testing for Java in
non-Web apps using jUnit, but couldn''t get into it in rails, especially
when
just experimenting to work out some of the details of my app. Now I''m
on
actually writing my app properly, I''m using rSpec. This feels far more
natural than ordinary tests, and it promotes good testing practises. I would
recommend trying rSpec for testing with. Here''s an example of a few
simple
specs to test relationships between models, combined with the code which
makes these specs pass. See how easy it is? http://pastie.caboo.se/61451

-Nathan

On 14/05/07, Phlip <phlip2005-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:>
>
> gino wrote:
>
> > what''s the difference beween testin the rails way, or just
using the the
> > browser?
>
> The same amount of testing that could take 5 seconds in automate tests,
> could take 5 days in manual tests.
>
> If your testing cycle is faster, you can run the tests more often. Run
> them
> after every few code edits, and always try to predict their outcome.
>
> That lets you know instantly when you make most mistakes. Not days later.
> And that lets you go faster, and take more risks.
>
> http://www.faisal.com/docs/ror-list-faq.html
>
> "Why do I need to write all these tests?
>
> "You don''t need to, but it''s probably a good idea if
you want your code to
> actually work. There is a technical answer and a philosophical reasons to
> test with Ruby (and, by implication, Rails).
>
> "The technical answer is that Ruby, like all dynamic languages, does
more
> at
> runtime and less at compile time. Accordingly, the compiler won''t
catch a
> lot of the sorts of things that Java and C#''s compilers would.
However, a
> test suite that exercises much of your code will tend to catch those
> problems.
>
> "The philosophical answer is that the Rails community tends to favor
Agile
> methods of software development, and Agile methods tend to favor
> test-heavy
> (often test-first or test driven) programming practices due to their
> flexibility.
>
> "In any case, Rails comes with a built in testing framework, and Rails
> developers tend to use the framework heavily."
>
> > I don''t like testing, I don''t know how, and it will
take time for me to
> > learn it
> > if using the browser is the same as testing? then I''m not
intrested in
> > testing with the framework
>
> I don''t like debugging. I don''t like having a bug, and
not knowing even
> what
> module to look in to find it. I don''t like writing
''p'' statements, then
> watching the server transcript while poking around the user interface
> looking for the bug. With tests, the odds of that kind of debugging goes
> way
> down.
>
> This requires you learn to write the tests. Unit tests are very important,
> and one of the hardest situations to test is a website. Some frameworks
> for
> much simpler programs don''t have any unit test framework. Rails is
unique
> in
> the programming industry for offering one of the best test frameworks in
> the
> world, and making it completely cover website testing.
>
> This presents a challenge to a neophyte, and I don''t really blame
you for
> finding it daunting. To learn testing for websites, even under Rails, you
> must work and work to figure out how to write those test cases, and then
> you
> must make them simple and flexible. Rails will help you, even as the
> website
> technology itself hinders you!
>
> > if it fails in the browser, it will fail in the test
> > if it fails in the test, it will fail in the browser
> > then what''s the difference ?
>
> It fails in the test automatically, instantly.
>
> It fails in the browser only after you click and click to force the tested
> situation. Even then, you might not notice the bug, because it might be
> one
> wrong variable in the database, not a big obvious problem on a web page.
>
> Next, if you add a new feature X, it might break an old feature Y. Under
> manual testing, you might only think to try X. Under automated testing,
> the
> tests you wrote for Y will still try to run, and they might report the
> problem.
>
> > What I care more is not to fail in the browser, because
that''s what it''s
> > for in the first place, to be browsed
> > if you can tall me a reason for testing, I will appreciate, that way
> > I''ll have a reason, and learn more happily
>
> Here''s how it works, after you learn it. I write a test for a
super-simple
> thing, such as submit a form:
>
>   def test_my_form
>      get :my_page
>      submit_form ''my_form''
>   end
>
> I run that and get it to fail. Then I add <form
id=''my_form'' ...> to the
> target page (usually inside a form_tag). Then the test passes.
>
> Then I repeat for the next feature. To add an edit field to my form, I
> make
> the test query the button''s existence:
>
>   def test_my_form
>      login_as :franklyn
>      get :my_page
>      submit_form ''my_form'' do
>         assert_equal ''franklyn'',
form[''my_edit_field''], value
>      end
>   end
>
> Then that fails, and I write the code to pass the test.
>
> The result is I write each simple feature twice, once as a test and again
> as
> code. Each feature is simple, so this does not slow me down.
>
> However, I rarely have to run the actual website now! That allows me to
> spend all my time adding features, and almost no time manually running the
> browser just to look at each feature I add. Watching each test pass is the
> same as running the browser and looking at the feature. The tests become
> my
> view into what the website is doing. If I am curious about a feature, I
> can
> write another test for it, and I always make sure that writing more tests
> is
> easy.
>
> > I am using only development for now, maybe in production is diffrent
>
> The best way to develop is with tests, early and often. If you delay such
> things until production, you will create a lot of nasty surprises. Writing
> tests at the same time as writing code is very easy, and adding tests
> after
> the code is extremely hard. Now is the time to develop good work habits.
>
> Rails, and testing, will put anyone into the top 1% of all programmers for
> speed and efficiency. Many programmers, including old ones who think they
> know everything, still refuse to write tests. The wild success of the
> Rails
> platform shows how productive they can be.
>
> --
>   Phlip
>   http://www.oreilly.com/catalog/9780596510657/
>   "Test Driven Ajax (on Rails)"
>   assert_xpath, assert_javascript, & assert_ajax
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

gino

2007-May-14 15:49 UTC

head link

Re: testing

Thanks for your advices, I really appreciate it,
That''s what I needed to get myself going

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Jason Roelofs

2007-May-14 15:58 UTC

head link

Re: testing

rSpec is the next level of testing, so to speak, for those of us who have
been practicing test driven development (TDD) for some time now. TDD
requires such a drastic change in development mind-set that I believe
it''s
very important for people to work on just TDD, get that down and understand
the whys and hows, before jumping into the philosophy of behaviour driven
design (BDD) of which rSpec is for.

Gino, if you have any specific questions about how to test parts of your
code, we will be glad to help.

Jason

On 5/14/07, gino
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:>
>
> Thanks for your advices, I really appreciate it,
> That''s what I needed to get myself going
>
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

mixplate

2007-May-14 16:05 UTC

head link

Re: testing

what book can easily explain how to test ror applications?

i just recently got ruby on rails e-commerce by Christian Hellsten, but 
am still i think id need something a little more basic for 
understanding.

thanks!


-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Jason Roelofs

2007-May-14 16:55 UTC

head link

Re: testing

Agile Web Development with Rails (
http://www.amazon.com/Agile-Development-Rails-Pragmatic-Programmers/dp/0977616630/ref=pd_bbs_sr_1/103-2079972-1383852?ie=UTF8&s=books&qid=1179161608&sr=8-1
)

Jason

On 5/14/07, mixplate
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:>
>
> what book can easily explain how to test ror applications?
>
> i just recently got ruby on rails e-commerce by Christian Hellsten, but
> am still i think id need something a little more basic for
> understanding.
>
> thanks!
>
>
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

njmacinnes-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

2007-May-14 18:27 UTC

head link

Re: testing

I''m not sure I agree with that. I reckon rSpec is an ideal place for
new
testers to start. The idea of specifying behaviour is what good tests should
do anyway, and rSpec/BDD encourages this. Plus, syntactically, it''s a
smaller step to go from no tests to rSpec than to go from no tests to
Test::Unit or whatever, because rSpec is much more easy to read.

On 14/05/07, Jason Roelofs
<jameskilton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:>
> rSpec is the next level of testing, so to speak, for those of us who have
> been practicing test driven development (TDD) for some time now. TDD
> requires such a drastic change in development mind-set that I believe
it''s
> very important for people to work on just TDD, get that down and understand
> the whys and hows, before jumping into the philosophy of behaviour driven
> design (BDD) of which rSpec is for.
>
> Gino, if you have any specific questions about how to test parts of your
> code, we will be glad to help.
>
> Jason
>
> On 5/14/07, gino <
rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:
> >
> >
> > Thanks for your advices, I really appreciate it,
> > That''s what I needed to get myself going
> >
> > --
> > Posted via http://www.ruby-forum.com/.
> >
> >
> >
> >
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Phlip

2007-May-14 20:11 UTC

head link

Re: testing

> Agile Web Development with Rails
Note: "Agile" is an industry code-word. Authors picked it to
sugar-coat the real meaning: "We will bore you to tears with all sorts
of yacking about tests, instead of just writing sexy features."

So calling it "Test-infected Web Development" basically
didn''t fly. ;-)

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

topfunky

2007-May-15 16:09 UTC

head link

Re: testing

On May 14, 1:59 am, gino
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:> I don''t like testing, I don''t know how, and it will take
time for me to
> learn it
Shameless plug: many people have viewed my screencast on Test-First
Development with Rails and have said that it cleared up months of
confusion in only 90 minutes. Only $9 here:

http://peepcode.com/products/test-first-development

Geoffrey Grosenbach
http://peepcode.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Rails - May 2007 - testing

testing

Re: testing

Re: testing

Re: testing

Re: testing

Re: testing

Re: testing

Re: testing

Re: testing

Re: testing