Test for Library Classes

Rails
1

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

2

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/

3

Thanks Philip :slight_smile:
your assert looks good :slight_smile:

4

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. :slight_smile:

regards,
Bala

5

Bala wrote:

  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. :slight_smile:

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

6

Thanks Phlip,

It really helped me, Thanks a lot.