logo       
Google Custom Search
    AddThis Social Bookmark Button

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

Subject: 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: dev-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxx

Try Searching:
servers, voip, java, networking, microsoft ...
<Prev in Thread] Current Thread [Next in Thread>