You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4php-dev@logging.apache.org by Christian Grobmeier <gr...@gmail.com> on 2009/05/07 08:36:06 UTC
Difficult Testcases
Hi there,
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?
Similar questions occur on SocketAppender or on
DailyRollingFileAppender or Syslog or PHP appender. Any ideas how
testcases can look here?
Cheers,
Christian
Re: LoggerAppenderSocket wire format (was Re: Difficult Testcases)
Posted by Christian Grobmeier <gr...@gmail.com>.
I created an issue for this, since is not a too easy task - I don't
want to get it lost.
Thanks ver ymuch for all the info
Cheers
Christian
On Wed, May 20, 2009 at 5:53 AM, Curt Arnold <ca...@apache.org> wrote:
>
> On May 19, 2009, at 2:08 AM, Christian Grobmeier wrote:
>
>>> I haven't looked at this, but I'm guessing that its wire format is not
>>> compatible with Chainsaw and log4j since they used their easiest
>>> implementation (Java serialization). log4cxx 0.9.7 had its own wire
>>> format,
>>> but it was dependent on the encoding, sizeof(int) and endianess so you
>>> had
>>> to match senders and receivers. In the current log4cxx, I've mimicked a
>>> valid Java serialization byte sequence and it can interact with Chainsaw
>>> and
>>> other tools that consume log4j serialized events.
>>
>> Is there any chance to read something somewhere about this?
>
> Some dissection of the wire format appears in
> https://issues.apache.org/jira/browse/LOGCXX-7. The file names are the
> comparison files from the unit tests
> (https://svn.apache.org/repos/asf/logging/log4j/trunk/tests/witness/serialization).
>
> The Java serialization spec is here:
> http://java.sun.com/javase/6/docs/platform/serialization/spec/protocol.html.
> That plus the log4j source code defines the wire format that log4j writes
> and Chainsaw consumes.
>
> The applicable log4cxx code is:
>
> https://svn.apache.org/repos/asf/logging/log4cxx/trunk/src/main/cpp/objectoutputstream.cpp
> https://svn.apache.org/repos/asf/logging/log4cxx/trunk/src/main/cpp/loggingevent.cpp (the
> last two methods particularly)
>
> and to a lesser degree:
>
> https://svn.apache.org/repos/asf/logging/log4cxx/trunk/src/main/cpp/socketappenderskeleton.cpp
> https://svn.apache.org/repos/asf/logging/log4cxx/trunk/src/main/cpp/socketappender.cpp
>
> log4j and log4cxx both have serialization tests in their unit tests.
>
>
>>
>>
>>> I think bringing that
>>> same approach over would likely make LoggerAppenderSocket more useful.
>>> If
>>> there is an existing receiver that depends on the current wire format,
>>> log4j
>>> compatible could be made as an option.
>>
>> I agree.
>>
>> However, having the bytesequence defined would help with testing, even
>> when we don't manage to get a spawned process in PHP (which is a bit
>> to extreme i would guess). I think a SocketMock would be enough.
>>
>> Christian
>
>
>
>
>
Re: LoggerAppenderSocket wire format (was Re: Difficult Testcases)
Posted by Curt Arnold <ca...@apache.org>.
On May 19, 2009, at 2:08 AM, Christian Grobmeier wrote:
>> I haven't looked at this, but I'm guessing that its wire format is
>> not
>> compatible with Chainsaw and log4j since they used their easiest
>> implementation (Java serialization). log4cxx 0.9.7 had its own
>> wire format,
>> but it was dependent on the encoding, sizeof(int) and endianess so
>> you had
>> to match senders and receivers. In the current log4cxx, I've
>> mimicked a
>> valid Java serialization byte sequence and it can interact with
>> Chainsaw and
>> other tools that consume log4j serialized events.
>
> Is there any chance to read something somewhere about this?
Some dissection of the wire format appears in https://issues.apache.org/jira/browse/LOGCXX-7
. The file names are the comparison files from the unit tests (https://svn.apache.org/repos/asf/logging/log4j/trunk/tests/witness/serialization
).
The Java serialization spec is here: http://java.sun.com/javase/6/docs/platform/serialization/spec/protocol.html
. That plus the log4j source code defines the wire format that log4j
writes and Chainsaw consumes.
The applicable log4cxx code is:
https://svn.apache.org/repos/asf/logging/log4cxx/trunk/src/main/cpp/objectoutputstream.cpp
https://svn.apache.org/repos/asf/logging/log4cxx/trunk/src/main/cpp/loggingevent.cpp
(the last two methods particularly)
and to a lesser degree:
https://svn.apache.org/repos/asf/logging/log4cxx/trunk/src/main/cpp/socketappenderskeleton.cpp
https://svn.apache.org/repos/asf/logging/log4cxx/trunk/src/main/cpp/socketappender.cpp
log4j and log4cxx both have serialization tests in their unit tests.
>
>
>> I think bringing that
>> same approach over would likely make LoggerAppenderSocket more
>> useful. If
>> there is an existing receiver that depends on the current wire
>> format, log4j
>> compatible could be made as an option.
>
> I agree.
>
> However, having the bytesequence defined would help with testing, even
> when we don't manage to get a spawned process in PHP (which is a bit
> to extreme i would guess). I think a SocketMock would be enough.
>
> Christian
Re: LoggerAppenderSocket wire format (was Re: Difficult Testcases)
Posted by Christian Grobmeier <gr...@gmail.com>.
> I haven't looked at this, but I'm guessing that its wire format is not
> compatible with Chainsaw and log4j since they used their easiest
> implementation (Java serialization). log4cxx 0.9.7 had its own wire format,
> but it was dependent on the encoding, sizeof(int) and endianess so you had
> to match senders and receivers. In the current log4cxx, I've mimicked a
> valid Java serialization byte sequence and it can interact with Chainsaw and
> other tools that consume log4j serialized events.
Is there any chance to read something somewhere about this?
> I think bringing that
> same approach over would likely make LoggerAppenderSocket more useful. If
> there is an existing receiver that depends on the current wire format, log4j
> compatible could be made as an option.
I agree.
However, having the bytesequence defined would help with testing, even
when we don't manage to get a spawned process in PHP (which is a bit
to extreme i would guess). I think a SocketMock would be enough.
Christian
LoggerAppenderSocket wire format (was Re: Difficult Testcases)
Posted by Curt Arnold <ca...@apache.org>.
On May 7, 2009, at 2:09 AM, Knut Urdalen wrote:
>
> 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.
>
I haven't looked at this, but I'm guessing that its wire format is not
compatible with Chainsaw and log4j since they used their easiest
implementation (Java serialization). log4cxx 0.9.7 had its own wire
format, but it was dependent on the encoding, sizeof(int) and
endianess so you had to match senders and receivers. In the current
log4cxx, I've mimicked a valid Java serialization byte sequence and it
can interact with Chainsaw and other tools that consume log4j
serialized events. I think bringing that same approach over would
likely make LoggerAppenderSocket more useful. If there is an existing
receiver that depends on the current wire format, log4j compatible
could be made as an option.
Re: Difficult Testcases
Posted by Curt Arnold <ca...@apache.org>.
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.
Re: Difficult Testcases
Posted by Knut Urdalen <kn...@php.no>.
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