[Zope-Coders] Help with Unit Testing
Chris Withers
chrisw@nipltd.com
Mon, 12 Aug 2002 19:03:05 +0100
Shane Hathaway wrote:
> Chris Withers wrote:
>
>> Tres Seaver wrote:
>> > +#
>> > +# XXX: 2002/08/12 Generic rule: *don't* do imports of the
>> module-under-test
>> > +# at module scope in the unittest; failure here suppresses
>> information!
>> > +#
>> > from Products.CMFCore.DirectoryView import registerDirectory
>> > from Products.CMFCore.DirectoryView import addDirectoryViews
>> > from Products.CMFCore.DirectoryView import DirectoryViewSurrogate
>>
>> Not sure I follow you here. This pattern is used all over the place. I
>> can see
>> what you're driving at but I'm not sure why these tests were picked
>> out as an
>> example? Should we change tests like these everywhere? will we? ;-)
>
>
> It's a new pattern that seems logical. Your tests were picked out only
> because they are new. :-) There are other patterns known to be bad in
> unit tests (like "assert" statements), but we haven't taken the time to
> clean up older tests, partly because we're not sure we've discovered all
> the right patterns yet.
So where should these imports be included now?
>> > +# and it should be possible to run them *anywhere*,
>> including in
>> > +# a setup where the files / directories are readonly.
>>
>> ..I don't think it's possible for this to be the case. Lots of the
>> Zope tests
>> (ZCatalog indexes, ZODB, etc) write to files.
>
> Do they? If you import the "Testing" package before importing "Zope",
> Zope.app() gives you a DemoStorage instead of a FileStorage.
Well, maybe someone can explain all the StorageErrors I get with the Windows
test runner then? ;-)
However, no-one has addressed the real problem yet, I'm afraid :-(
DirectoryViews, are, unfortunately predictated on the filesystem. They need to
be tested, and the only way I can think of to do this is to modify files on the
filesystem.
Until someone can suggest a better way, I propose that this form of testing
remains as it is.
Anyone got any suggestions?
cheers,
Chris