[Nitro] Og Unit Tests

Bryan Soto bryan.a.soto at gmail.com
Thu Jan 19 17:25:17 EST 2006

Okay list, there are two problems with the unit tests which are both

1. Resolve polymorphic relations:

E, [2006-01-19T13:49:28.405806 #22605] ERROR -- : Og.setup had problems:
TypeError => (eval):2:in `resolve_polymorphic_relations': superclass
mismatch for class Comment
E, [2006-01-19T13:49:28.406438 #22605] ERROR -- : #<TypeError: (eval):2:in
`resolve_polymorphic_relations': superclass mismatch for class Comment>

2. Multiple uses of Og.setup

$ grep -R Og.setup * | wc -l

Basically, the problem is this. Each call to Og.setup results in Og
iterating over all the classes in ObjectSpace to find Classes it can manage.
Because there are multiple calls to Og.setup, classes are "managed" multiple
times, which ultimately causes this

  class TC_OgPolymorphic::User::Comment < TC_OgPolymorphic::User::Comment

to be evaled which results in the TypeError listed in item one. Note that
the super and sub class are both the same name.

Now, I'm personally of the opinion that there shouldn't be multiple calls to
Og.setup strewn throughout the test code. I think it should be all done via
the config file that way all tests run against a single store. This also has
the benefit that if a store isn't up to par with Postgres, it'll show up as
an error. But I also recognize that what is happening with the type error is
a bug which should be corrected. The attached patch, not bundle as I'm not
sure this is the right solution, simply checks to see if we attempt to
create a super and sub class of the same name and skips over it. It allows
the tests to run with easier to correct errors, i.e. hardcoded passwords,
hardcoded stores, etc. These, of course, are easily correctted by having
only a single Og.setup call. :)

Anyway, I'm happy to take care of the Og.setup issue, but didn't actually do
a bundle in case there are valid reasons why it shouldn't be done. Wasted
effort and all that.

I did actually comment out all the Og.setup calls last night, and going by
my memory (be wary given recent performance ;), the results were:

* 1 test which needed to be skipped (renamed to xtest_* due to a
non-existent database field)
* 13 errors
* 4 failures

So this is probably something to address for 0.28. ;)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060119/f78ae179/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_resolve_polymorphic_relations
Type: application/octet-stream
Size: 564 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060119/f78ae179/attachment.obj 

More information about the Nitro-general mailing list