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