Hi Experts, Sorry if this questions makes you irritate. how do we write test for library classes? for ex: i''ve class testing.rb in lib folder. regards, Bala --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Bala wrote:> Sorry if this questions makes you irritate.All questions make me irritate other people here. (-: > how do we write test for> library classes? > > for ex: i''ve class testing.rb in lib folder.If you have a file lib/foo.rb, test it with test/unit/foo_test.rb. That''s why the folder is "test/unit", not "test/model". And BTW use my awesome assert{ 2.0 } in your test cases, to make them even easier to write. -- Phlip http://assert2.rubyforge.org/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Thanks Philip :) your assert looks good :) On Mar 6, 8:29 pm, Phlip <phlip2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Bala wrote: > > Sorry if this questions makes you irritate. > > All questions make me irritate other people here. (-: > > > how do we write test for > > > library classes? > > > for ex: i''ve class testing.rb in lib folder. > > If you have a file lib/foo.rb, test it with test/unit/foo_test.rb. > > That''s why the folder is "test/unit", not "test/model". > > And BTW use my awesome assert{ 2.0 } in your test cases, to make them even > easier to write. > > -- > Phlip > http://assert2.rubyforge.org/--~--~---------~--~----~------------~-------~--~----~ 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,
I''ve a method like this, on lib/foo.rb class.
def import_some_data(opt = {})
if opt[:arg1] && opt[:arg2] && opt[:arg3]
doc = parse_three_args(opt[:arg1], opt[:arg2], opt[:arg3])
elsif opt[:arg1] && opt[:arg2]
doc = parse_two_arg(opt[:arg2])
elsif opt[:arg1]
doc = parse_one_arg(opt[:arg1])
else
doc = nil
end
parse_it(doc) if !doc.nil?
check_for_multiple_instance(opt[:multiple_instance], doc) if !
doc.nil?
end
now is there way to write good test on this method? honeslty i''m so
weak in testing. :)
regards,
Bala
On Mar 7, 10:12 am, Bala <mbb...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> Thanks Philip :)
> your assert looks good :)
>
> On Mar 6, 8:29 pm, Phlip
<phlip2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > Bala wrote:
> > > Sorry if this questions makes you irritate.
>
> > All questions make me irritate other people here. (-:
>
> > > how do we write test for
>
> > > library classes?
>
> > > for ex: i''ve class testing.rb in lib folder.
>
> > If you have a file lib/foo.rb, test it with test/unit/foo_test.rb.
>
> > That''s why the folder is "test/unit", not
"test/model".
>
> > And BTW use my awesome assert{ 2.0 } in your test cases, to make them
even
> > easier to write.
>
> > --
> > Phlip
> > http://assert2.rubyforge.org/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Bala wrote:> I''ve a method like this, on lib/foo.rb class. > > def import_some_data(opt = {}) > if opt[:arg1] && opt[:arg2] && opt[:arg3] > doc = parse_three_args(opt[:arg1], opt[:arg2], opt[:arg3]) > elsif opt[:arg1] && opt[:arg2] > doc = parse_two_arg(opt[:arg2]) > elsif opt[:arg1] > doc = parse_one_arg(opt[:arg1]) > else > doc = nil > end > parse_it(doc) if !doc.nil? > check_for_multiple_instance(opt[:multiple_instance], doc) if ! > doc.nil? > end > > now is there way to write good test on this method? honeslty i''m so > weak in testing. :)Pretend the method did not exist yet, and write one test for one line in the method. Suppose I pick the line parse_one_arg. I want to write a test that proves it did not exist yet. I would write this (renaming your function to importer()): def test_importer_parses_one_arg doc = importer(:arg1 => ''my data'') assert{ doc.get_data == ''my data'' } end (Hit http://assert2.rubyforge.org/ to write simple but powerful assert{} statements like that! Otherwise, that''s the same as assert_equal()...) To pass that assertion, I must make importer() a little more "exposed" and "decoupled". It must return the ''doc'' that it created, and this ''doc'' must have a method to tells us what the parse did. Here''s the importer() to pass that test: def importer(opts) doc = parse_one_arg(opt[:arg1]) return nil unless doc parse_it(doc) check_for_multiple_instance(opt[:multiple_instance], doc) return doc end The method does not do anything that the test didn''t ask for (except the nil-handling, which is always a good idea anyway). If you want more stuff in that function, you must write another test, first: def test_importer_parses_two_args doc = importer(:arg1 => ''my data'', :arg2 => ''more data'') assert{ doc.get_data == ''my data, more data'' } end Run that test, and make sure it fails for the correct reason. Make sure the assert prints out a diagnostic describing exactly what''s wrong. Only then should you upgrade importer(): def importer(opts) doc = if opts[:arg1] and opts[:arg2] parse_two_args(*opts.values_at(:arg1, :arg2)) elsif opts[:arg1] parse_one_args(opts[:arg1]) else nil end return nil unless doc parse_it(doc) check_for_multiple_instance(opt[:multiple_instance], doc) return doc end This process is called "test driven development". Always run your tests after every few edits, always try to predict the result of the next run, and never write new code until you can get a test to fail for the right reason. If the tests fail, Undo or revert until they pass. This process does not require you to be good at testing. You just pretend that you are very bad at programming - so bad that you must always have a test to show you the next thing to do. -- Phlip --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Thanks Phlip, It really helped me, Thanks a lot. On Mar 7, 12:27 pm, Phlip <phlip2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Bala wrote: > > I''ve a method like this, on lib/foo.rb class. > > > def import_some_data(opt = {}) > > if opt[:arg1] && opt[:arg2] && opt[:arg3] > > doc = parse_three_args(opt[:arg1], opt[:arg2], opt[:arg3]) > > elsif opt[:arg1] && opt[:arg2] > > doc = parse_two_arg(opt[:arg2]) > > elsif opt[:arg1] > > doc = parse_one_arg(opt[:arg1]) > > else > > doc = nil > > end > > parse_it(doc) if !doc.nil? > > check_for_multiple_instance(opt[:multiple_instance], doc) if ! > > doc.nil? > > end > > > now is there way to write good test on this method? honeslty i''m so > > weak in testing. :) > > Pretend the method did not exist yet, and write one test for one line in the method. > > Suppose I pick the line parse_one_arg. I want to write a test that proves it did > not exist yet. I would write this (renaming your function to importer()): > > def test_importer_parses_one_arg > doc = importer(:arg1 => ''my data'') > assert{ doc.get_data == ''my data'' } > end > > (Hithttp://assert2.rubyforge.org/to write simple but powerful assert{} > statements like that! Otherwise, that''s the same as assert_equal()...) > > To pass that assertion, I must make importer() a little more "exposed" and > "decoupled". It must return the ''doc'' that it created, and this ''doc'' must have > a method to tells us what the parse did. > > Here''s the importer() to pass that test: > > def importer(opts) > doc = parse_one_arg(opt[:arg1]) > return nil unless doc > parse_it(doc) > check_for_multiple_instance(opt[:multiple_instance], doc) > return doc > end > > The method does not do anything that the test didn''t ask for (except the > nil-handling, which is always a good idea anyway). If you want more stuff in > that function, you must write another test, first: > > def test_importer_parses_two_args > doc = importer(:arg1 => ''my data'', :arg2 => ''more data'') > assert{ doc.get_data == ''my data, more data'' } > end > > Run that test, and make sure it fails for the correct reason. Make sure the > assert prints out a diagnostic describing exactly what''s wrong. Only then should > you upgrade importer(): > > def importer(opts) > doc = if opts[:arg1] and opts[:arg2] > parse_two_args(*opts.values_at(:arg1, :arg2)) > elsif opts[:arg1] > parse_one_args(opts[:arg1]) > else > nil > end > return nil unless doc > parse_it(doc) > check_for_multiple_instance(opt[:multiple_instance], doc) > return doc > end > > This process is called "test driven development". Always run your tests after > every few edits, always try to predict the result of the next run, and never > write new code until you can get a test to fail for the right reason. If the > tests fail, Undo or revert until they pass. > > This process does not require you to be good at testing. You just pretend that > you are very bad at programming - so bad that you must always have a test to > show you the next thing to do. > > -- > Phlip--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---