You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2005/03/09 11:11:53 UTC
Is BuildFileTest$AntTestListener doing the right thing?
Hi,
while looking into the ant-contrib test failures in Gump I revisited
our logging system for the first time since long.
Consider I have a task that does log("Some message\n").
Project#fireMessageLogged() will then strip the \n (at leat on Unix)
and DefaultLogger will re-add it for the output.
AntTestListener in turn will not add a new-line but simply concatenate
all log output into a StringBuffer.
If I now say assertLogContaining("Some message\n") it fails. Should
it? Yes, I know, I shouldn't use \n in my log message in the first
place, but still.
Now say I'm doing
log("line1");
log("line2");
in the task. I have to assert that the log contains "line1line2"
right now, which is rather ugly and unreadable. Again, should it be
that way?
I guess we'd break quite a few tests if we change the behavior,
though.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Is BuildFileTest$AntTestListener doing the right thing?
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 09 Mar 2005, Peter Reilly <pe...@apache.org> wrote:
> Removing the new-lines has made the tests easy to write.
Really?
> - I do not find it too ugly!
8-)
> However, I suppose that an argument may be made that the test is
> not actually looking at what a task outputs to a user
> and one should test for that.
Yes, that's pretty much what I think as well - even though only
DefaultLogger adds the new-lines, XmlLogger doesn't.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Is BuildFileTest$AntTestListener doing the right thing?
Posted by Peter Reilly <pe...@apache.org>.
Stefan Bodewig wrote:
>Hi,
>
>while looking into the ant-contrib test failures in Gump I revisited
>our logging system for the first time since long.
>
>Consider I have a task that does log("Some message\n").
>Project#fireMessageLogged() will then strip the \n (at leat on Unix)
>and DefaultLogger will re-add it for the output.
>
>AntTestListener in turn will not add a new-line but simply concatenate
>all log output into a StringBuffer.
>
>If I now say assertLogContaining("Some message\n") it fails. Should
>it? Yes, I know, I shouldn't use \n in my log message in the first
>place, but still.
>
>Now say I'm doing
>
> log("line1");
> log("line2");
>
>in the task. I have to assert that the log contains "line1line2"
>right now, which is rather ugly and unreadable. Again, should it be
>that way?
>
>I guess we'd break quite a few tests if we change the behavior,
>though.
>
Yes, a lot.
Removing the new-lines has made the tests easy to write.
- One does not need to worry about \r, \r\n or \n issues
when looking at the output.
- I do not find it too ugly!
However, I suppose that an argument may be made that the test is
not actually looking at what a task outputs to a user
and one should test for that.
Peter
>
>Stefan
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Is BuildFileTest$AntTestListener doing the right thing?
Posted by Steve Loughran <st...@apache.org>.
Stefan Bodewig wrote:
> Hi,
>
> while looking into the ant-contrib test failures in Gump I revisited
> our logging system for the first time since long.
>
> Consider I have a task that does log("Some message\n").
> Project#fireMessageLogged() will then strip the \n (at leat on Unix)
> and DefaultLogger will re-add it for the output.
>
> AntTestListener in turn will not add a new-line but simply concatenate
> all log output into a StringBuffer.
>
> If I now say assertLogContaining("Some message\n") it fails. Should
> it? Yes, I know, I shouldn't use \n in my log message in the first
> place, but still.
>
> Now say I'm doing
>
> log("line1");
> log("line2");
>
> in the task. I have to assert that the log contains "line1line2"
> right now, which is rather ugly and unreadable. Again, should it be
> that way?
I'd go for including \n into the tests, with caveats. The risk is not
that Ant's own tasks break -whcih we can fix-, but that third party ant
tasks tests break. We've never made guarantees of ant-testutils.jar
being consistent, but third party projects will want to be able to build
against both 1.6 and 1.7 ant, so dont wan't a gratuitous break.
Why not put the change in and we'll see what breaks in terms of
ant-contrib and others.
What I prefer, incidentally, is for tasks to declare strings as
constants and then you refer to them in the test...I write all my tests
that way, because it stops my tests being so brittle to change.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org