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 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 groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. 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 frameworkI 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 happilyHere''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 diffrentThe 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 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 groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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? 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. > > 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 > 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 groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks for your advices, I really appreciate it, That''s what I needed to get myself going -- Posted via 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 groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 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 groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 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 groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Agile Web Development with Rails ( 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 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 groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 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 groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> Agile Web Development with RailsNote: "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 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 groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 itShameless 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: peepcode.com/products/test-first-development Geoffrey Grosenbach 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 groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---