HTML Purifier and SimpleTest

Here is a compilation of "hidden" SimpleTest
methods/properties that
HTML Purifier is mucking around with:

1. I have a custom base harness that overloads getTests() in
order to
allow me to prepend __only to test methods in order to test
only that
method. When it's on, I send a custom skip message to
simpleTest.
Affected member variables: SimpleTestCase->_reporter to
send the skip
message

2. Another custom unit test is FailedTest, which fails the
entire suite
if there were problems with some global initialization code.
Affected
member variables: SimpleTestCase->_reporter, in order to
output
multiline details of what failed

3. A shutdown error function dumps the error queue if there
was a fatal
error. This is useful because notices and warnings can often
be
precursors to fatal errors, and outputting them helps
debugging.
Affected member variables: SimpleErrorQueue->_queue to
grab the errors.
I suppose I could use extract, but it was quicker to access
the queue
itself.

4. A implementation of CliTestCase. This probably should get
stuffed
into the core, actually. I couldn't figure out a suitable
parent class
to inherit from.

5. A custom HTML reporter, overloads _getCss to add one
extra line of CSS.

6. Another custom test-case for interfacing with PHPT, uses
SimpleTestCase->_reporter in order to setup an adapter
for PHPT's reporter.

I could argue 1, 3 and 4 could go into the core (1 is most
tenuous, but
I've found it useful when debugging). 2 stems from a lack of
a generic
function in SimpleTestCase for sending messages (such an
interface would
also benefit 1, as skip is a little hacky). 5 is a good case
for
protected. 6 I could refactor to call SimpleTestCase's
methods, but that
would be very awkward; I think _reporter should also be
protected, or
accessible with a getter.

-- 
 Edward Z. Yang                        GnuPG: 0x869C48DA
 HTML Purifier <http://htmlpurifier.org&g
t; Anti-XSS Filter
 [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]

------------------------------------------------------------
-------------
This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference 
Don't miss this year's exciting event. There's still time to
save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;1987
57673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Simpletest-support mailing list
Simpletest-supportlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simp
letest-support

Hi...

Edward Z. Yang wrote:
> 1. I have a custom base harness that overloads
getTests() in order to
> allow me to prepend __only to test methods in order to
test only that
> method. When it's on, I send a custom skip message to
simpleTest.
> Affected member variables: SimpleTestCase->_reporter
to send the skip
> message

I thought getTests() was public.

> 
> 2. Another custom unit test is FailedTest, which fails
the entire suite
> if there were problems with some global initialization
code. Affected
> member variables: SimpleTestCase->_reporter, in
order to output
> multiline details of what failed

Why couldn't you use skip?

> 
> 3. A shutdown error function dumps the error queue if
there was a fatal
> error. This is useful because notices and warnings can
often be
> precursors to fatal errors, and outputting them helps
debugging.
> Affected member variables: SimpleErrorQueue->_queue
to grab the errors.
> I suppose I could use extract, but it was quicker to
access the queue
> itself.

I think this is the job for the new Recorder, which should
probably be 
in core.

> 
> 4. A implementation of CliTestCase. This probably
should get stuffed
> into the core, actually. I couldn't figure out a
suitable parent class
> to inherit from.

Is that the same as the ShellTestCase?

> 
> 5. A custom HTML reporter, overloads _getCss to add one
extra line of CSS.

getCss() is protected exactly for this reason.

> 
> 6. Another custom test-case for interfacing with PHPT,
uses
> SimpleTestCase->_reporter in order to setup an
adapter for PHPT's reporter.

Can you not write a custom reporter for this? How does this
interfacing 
work?

> 
> I could argue 1, 3 and 4 could go into the core (1 is
most tenuous, but
> I've found it useful when debugging).

1 is cool. In SimpleTest 2 I am entertaining the idea that a
test is a 
test if it's public. This means that the leading
"test" is not needed 
and people can name methods as they please.

If you want to filter methods, have a look at the
InvokerDecorator and 
ReporterDecorator. the DefaultReporter uses them to run a
specific test.

 > 2 stems from a lack of a generic
> function in SimpleTestCase for sending messages (such
an interface would
> also benefit 1, as skip is a little hacky).

It's called signal(). The worlds most undocumented method.
Take a look... 

 > 5 is a good case for
> protected.

Yes. Was it not marked as such in the doc blocks? My bad if
it wasn't.

 > 6 I could refactor to call SimpleTestCase's methods,
but that
> would be very awkward; I think _reporter should also be
protected, or
> accessible with a getter.
> 

The preferred mechanisms of integration are custom reporters
and the XML 
interface. If you are trying to translate PHPT tests into
SimpleTest, 
then a custom test case similar to the one in xml.php would
be a nice 
extension ;).

yours, Marcus
-- 
Marcus Baker
marcuslastcraft.com

------------------------------------------------------------
-------------
This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference 
Don't miss this year's exciting event. There's still time to
save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;1987
57673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Simpletest-support mailing list
Simpletest-supportlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simp
letest-support

On Wed, Apr 9, 2008 at 1:09 PM, Marcus Baker <marcuswordtracker.com> wrote:
>  1 is cool. In SimpleTest 2 I am entertaining the idea
that a test is a
>  test if it's public. This means that the leading
"test" is not needed
>  and people can name methods as they please.

Very nice idea.

--
troels

------------------------------------------------------------
-------------
This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference 
Don't miss this year's exciting event. There's still time to
save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;1987
57673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Simpletest-support mailing list
Simpletest-supportlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simp
letest-support

Marcus Baker wrote:
> I thought getTests() was public.

Yah, I'm not worried about that. 
Interacting with _reporter is the
problem, but as you mention below, signal is the way to go
about it.

> Why couldn't you use skip?

All of my "regular" tests are dependent on this
maintenance script, so
I'd have to put the skip in all of them. Much simpler to
circumvent that
test suite and run FailedTest; and simply exit'ing isn't an
option since
the data may be martialed together as XML.

> I think this is the job for the new Recorder, which
should probably be 
> in core.

Ooh, shiny new Recorder! (never heard of it) Looking forward
to see it.

> Is that the same as the ShellTestCase?

I'm pretty sure they're different. CliTestCase is a bit
like
RemoteTestCase, only instead of making an http request you
run a command
and parse the XML output. ShellTestCase seems to be a test
case used for
testing shell scripts.

> getCss() is protected exactly for this reason.

Remove the underscore then?

> Can you not write a custom reporter for this? How does
this interfacing 
> work?

PHPT Core
  -> PHPT Reporter (SimpleTest implementation, I wrote
this)
  -> SimpleTest Reporter

which is, I think, what you suggested.

> 1 is cool. In SimpleTest 2 I am entertaining the idea
that a test is a 
> test if it's public. This means that the leading
"test" is not needed 
> and people can name methods as they please.
> 
> If you want to filter methods, have a look at the
InvokerDecorator and 
> ReporterDecorator. the DefaultReporter uses them to run
a specific test.

Haha, I'm still in the stone ages; I'm using an extended
HTMLReporter
with command line/web UI parsing bolted on. I'll have to
investigate
DefaultReporter and see if it reaches feature parity with my
custom
solution.

The reason why I think (1) would be useful is because the
reason why
you'd want to filter a specific method is because you're
debugging the
code; to use DefaultReporter you'd have to specify an extra
flag on the
browser with the exact test-case name and method name to
filter out;
with my implementation you just tack on __only and are done
with it (the
code would presumably be in front of you anyway).

> It's called signal(). The worlds most undocumented
method. Take a look... 

Gotcha.

> Yes. Was it not marked as such in the doc blocks? My
bad if it wasn't.

It is indeed protected. My bad.

> The preferred mechanisms of integration are custom
reporters and the XML 
> interface. If you are trying to translate PHPT tests
into SimpleTest, 
> then a custom test case similar to the one in xml.php
would be a nice 
> extension ;).

Hmm... that feels really inefficient, because I'd be
generating XML that
SimpleTest would immediately be parsing afterwards, and
since I'd be
reusing the XMLReporter to do the XML generation, why not
just swap out
XMLReporter with whatever the active reporter is?

If I haven't been clear about how this implementation works,
please say
so and I'll elaborate in detail.

-- 
 Edward Z. Yang                        GnuPG: 0x869C48DA
 HTML Purifier <http://htmlpurifier.org&g
t; Anti-XSS Filter
 [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]

------------------------------------------------------------
-------------
This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference 
Don't miss this year's exciting event. There's still time to
save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;1987
57673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Simpletest-support mailing list
Simpletest-supportlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simp
letest-support

Marcus Baker wrote:
> I usually advise creating projects specific test cases
right at the
> beginning...
> 
> class PurifierTestCase extends UnitTestCase {
>     function skip() { ... }
> }

My head is being a little obtuse at the moment, so I don't
understand.
Is PurifierTestCase a supertype for all my test-cases?

> Ah, now I see. I want to add an IsolatedTestCase, which
runs a script,
> which is an autorun script, with the --xml flag.
Similar to the remote
> test case, this allows knotty tests to run in their own
process.

That sounds like it!

> Yep. Needs to be mentioned in the
HELP_MY_TESTS_DONT_WORK_ANYMORE file.

Done.

> It's more about reusing the mechanism.

Agreed. I'll play around with the decorators.

> I think that this is too specific to your way of
working to place in the
> core.

That's not a problem. I was just curious to know if anyone
else found
something like that useful.

> It has to work with decorators and all sorts of other
things. It will
> likely get changed in a later release as well, and it
kinda' couples a
> lot of stuff together across packages. And switching
reporter mid test
> could cause all sorts of issues if they were using a
Recorder. It
> worries me. How does it play with Eclipse?

The reporter isn't getting switched. Instead of the usual

UnitTestCase
  -> *Reporter

it becomes

UnitTestCase
  -> PHPTTest
  -> PHPTReporter
  -> *Reporter

The *Reporter object can't tell that there was as another
"reporter"
adapting PHPTTest's data to it. It also works with
decorators; just
extend the call-tree of *Reporter. I might be missing
something though...

Here's the code:

Extends SimpleTestCase as a PHPT test-case which invokes
PHPT
http://htmlpurifier.org/s
vnroot/htmlpurifier/trunk/tests/PHPT/Controller/SimpleTest.p
hp

Reporter adapter called by PHPT which forwards calls to
active reporter
http://htmlpurifier.org/svn
root/htmlpurifier/trunk/tests/PHPT/Reporter/SimpleTest.php

-- 
 Edward Z. Yang                        GnuPG: 0x869C48DA
 HTML Purifier <http://htmlpurifier.org&g
t; Anti-XSS Filter
 [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]

------------------------------------------------------------
-------------
This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference 
Don't miss this year's exciting event. There's still time to
save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;1987
57673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Simpletest-support mailing list
Simpletest-supportlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simp
letest-support