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

Thanks, Paul. I've got the PHPUnit up and running.

\r by itself is now converted to \n, immediately after "\r\n" & "\n\r" 
are converted to \n as well. Thus, \r is recognized as required. This 
was ommitted in earlier versions.

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.

Thus your 84 tests now complete without failure.

I'll take over and start writing my own now as per testing guidelines.

I may be some time... ;)

Archie

PAUL HANCHETT wrote:

> Here they are.  The only existing "problem" I now see with the parser 
> is that \r by itself isn't recognized as a paragraph end.  Accounting 
> for it is more by way of defensive programming, I don't know of any 
> system that will really give us that line end...
>
> If you notice tests that I missed, by all means add them...  No need 
> to get *too* wild and crazy but being comprehensive here will keep it 
> from being a problem later.  :-)
>
> As a matter of priority, I'm really more interested in getting the 
> round trip stuff working...  If we can close that loop then we can 
> certify that the whole parser is ready to go.  I'd like *that* very 
> much!  :-)
>
> If you can help me resolve that I18N issue, I'll look at closing the 
> loop up.  I'm sure there are wrinkles I'll need to address.
>
> Archie Campbell wrote:
>
>> Paul,
>>
>> OK. I hadn't appreciated the scope of the move to unit-tests. I'm 
>> willing to play along.
>>
>> Could you send me the latest parser tests, and the latest 
>> test-harness files - I've lost them.
>>
>> Ok. Sorry for sulking so publicly. I'll start with providing 
>> something for every preg_match, and then some form of sensible 
>> cross-questioning. i.e. ...
>>
>> I'll write ParserLineStartArteriskListFormattingTest ->
>>    ->testRunIntoText text survival and insertion of space
>>    ->testRunIntoNoText no problem keep the extra bullet with its 
>> extra line
>>    ->testTableOnLine table survives
>>    ->testSingleEolnEndsList
>>    ->testPipedAttributeInsertion attribute faithfully transcribed
>>    ->testPipedAttributeNoPipeOmission threatens monster insertion of 
>> bad text, fail to attribute & make text
>>    ->testNumberOfAsterisks faithfully become embedded lists
>>
>> and then do very similar for ParserLineStartHashListFormattingTest, 
>> which is no problem with my groovy emacs php-mode frustration-busting 
>> setup.
>>
>> Ok.
>>
>> Could be very worthwhile.
>>
>> For what it's worth, I'm sure dtg's coding guidelines are motivated 
>> by more than his 80-line editor.
>>
>> So I'll be outputting nicely formatted test cases whether or not the 
>> extant files are guidelined or not.
>>
>> This will take some time and likely some questions.
>>
>> Regards,
>>
>> Archie
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>