Re: [cowiki-dev] Unit tests, here I come.

Archie Campbell <[email protected]>
Newsgroups gmane.comp.php.cowiki.devel
Message-ID <[email protected]>
PAUL HANCHETT wrote:

>> The I18N issue arose because CoWikiReverseParser uses RuntimeContext 
>> to access the database when arranging links (in BuildIdRefLink). I've 
>> shoehorned a replacement that inherits from WikiReverseParser named 
>> 'TestReverseParser'. The new class ignores complexity and returns 
>> ((Where)(Name)) or [[Where][Name]] for links without troubling the 
>> database.
>
> Would it be better to provide an alternate definition (a stub of some 
> sort) for RuntimeContext?  Then there would be no possibility of 
> changes in the constructor of WikiReverseParser leading to untested 
> code or false errors.

I think not. CoWikiReverseParser uses RuntimeContext to deliver 
instances of the DocumentDAO and manipulates database Nodes and the 
like. Although we might want to test link manufacture with real database 
manipulation at some point, we can use CoWikiReverseParser in all its 
database-bothering glory with some fake data at that point, and get away 
with ignoring the code at present. The point is that returning 
[[link][name]] at present is good enough for formatting and syntax 
tests. We can test that 'link' and 'name' are the correct quantities in 
more thorough, database-savvy tests at a later date.

> OK, so you want me to lay off doing more.  Right?  ;-)  Will you also 
> propose a way to integrate the unit tests into the coWiki source 
> tree?  Issues I see are:
>
>     * One source at the top can invoke all unit tests
>     * Unit tests are broken into sub-parts which can be run
>       independently.  (The parser tests we are developing might be an
>       example subpart.)
>     * It's helpful if unit tests for a class are located close to the
>       class.  At the same time you don't want them to become clutter.  :-)
>
I suppose the easiest thing would be to create a test directory (an the 
level of misc), and populate it with files on the order of 
'unittest.php', but named test.ParserTest.php, class.WebNodeTest.php or 
what have you. A file like setup.php which runs to completion if all is 
ready would be nice. One would run CoWikiTestAll.php or the separate 
test.X.php files to one's heart's content.

I'm not sure that placing unit tests near to the class is really 
necessary. It's going to be pretty obvious they'll live in the /test 
directory, isn't it?

Regards,

Archie
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.