On May 7, 2009, at 2:09 AM, Knut Urdalen wrote:
Christian Grobmeier wrote:
I am looking over possible testcases at the moment.
We have a MailAppender which creates mails on event. How can we test
this? Do we have an "test mail account"? How can we deal with delays
in mailing, when Continuus Int. is on?
The result of unit testing email sending isn't worth much for the
receiver so maybe we should create a mock object [1] here? I've not
used it extensively.
Similar questions occur on SocketAppender or on
DailyRollingFileAppender or Syslog or PHP appender. Any ideas how
testcases can look here?
1) LoggerAppenderPhp uses trigger_error() to raise PHP user errors.
To catch these messages you need to define an error handler with
set_error_handler() [2] (you should probably call
restore_error_handler() [3] afterwards).
2) LoggerAppenderSocket is a bit more complicated. It uses
fsockopen() to connect to a socket. I have written an example using
PEAR::Net::Server [4] (see examples/client.php and examples/
server.php) that I've used as a experimental central logging server
before. I think it's possible to write a unit test case here which
startup the socket server and connect with a client (but you need to
manage two different processes here which is hard in PHP, I only
know about the pcntl-extension [] used for spawning processes on
*nix). If you write a test case for this remember to use
self::markTestSkipped('With some useful message'); [6] if the test
case is unable to run because of missing dependencies.
3) LoggerAppenderDailyFile should be possible to test by setting the
date pattern (with LoggerAppenderDailyFile::setDatePattern) to
different things and check the outcome.
4) LoggerAppenderRollingFile should be possible to test by setting
the maximum filesize (with
LoggerAppenderRollingFile::setMaxFileSize) to something useful and
do some logging that results in rolling files.
5) LoggerAppenderSyslog I would say is ok to use directly and check
the syslog file? Maybe we can workaround this and pipe syslog
messages somewhere else not to mess up the syslog on the machine?
Remember to write any temporary data into target/test (not within)
src/test/php (I just saw that the LoggerAppenderPDOTest is writing
and deleting a temporary sqlite database inside src/test/php/
appenders).
Hope this helps! :)
Knut
[1] http://www.phpunit.de/manual/3.2/en/mock-objects.html
[2] http://php.net/set_error_handler
[3] http://php.net/restore_error_handler
[4]
http://svn.apache.org/viewvc/incubator/log4php/trunk/src/examples/php/server.php?view=markup
[5] http://php.net/pcntl
[6] http://www.phpunit.de/manual/3.3/en/incomplete-and-skipped-tests.html
I'd suggest trying to transliterate existing log4j test cases in
preference to formulating brand new test cases. Makes it easier to
see where the implementations diverge.
The SMTP appender would likely need to fire up some listener (either
James or something) on high port and not depend on the default SMTP
server on the system. I don't think the log4j test suite does that at
the moment. It does spin up a receiver for the socket appenders.
