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