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

Archie Campbell wrote:

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

Excellent!

>
> \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.

Great!  I think this is the way to do it.  We won't get reports of 
problems from some odd system this way.

>
> 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.

>
> 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... ;)

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 guess that's enough "advice"!

I'm glad you're taking up the mantle of doing unit testing!  Let me know 
if you need someone to come along side you.

Paul

>
> 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]
>>