You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Oleg Taranenko <ot...@key-software.com> on 2007/05/25 14:26:41 UTC
Build Failed
Hi, all
just now I checkout the last version of the Wicket from the scratch
https://svn.apache.org/repos/asf/incubator/wicket/trunk
mvn package (and mvn install) failed:
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 23 seconds
[INFO] Finished at: Fri May 25 14:19:51 CEST 2007
[INFO] Final Memory: 14M/35M
[INFO] ------------------------------------------------------------------------
Failure is at:
=== org.apache.wicket.markup.html.basic.SimplePage_12 ===
=== org.apache.wicket.markup.html.basic.SimplePage_13 ===
=== org.apache.wicket.markup.html.basic.SimplePage_14 ===
[surefire] Tests run: 16, Failures: 1, Errors: 0, Time elapsed: 0,531 sec <<<<<<<< FAILURE !!
[surefire] Running org.apache.wicket.markup.html.basic.SimpleResponsePageClassTest
[surefire] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,047 sec
[surefire] Running org.apache.wicket.markup.html.border.BoxBorderTest
=== org.apache.wicket.markup.html.border.BoxBorderTestPage_1 ===
=== org.apache.wicket.markup.html.border.BoxBorderTestPage_2 ===
What do I wrong?
Thanks
Newbie in wicket,
Oleg
Re: Build Failed
Posted by Oleg Taranenko <ot...@key-software.com>.
Thank you for detailed explanation, without test step the build works.
> You don't do anything wrong.
> In Wicket development (on the core project), the unit tests sometimes
> just don't run for a couple of days because they are used as a method
> of communication: someone knows how to reproduce a bug but doesn't
> know how to fix it. The unit test exposing the bug is then committed,
> so that someone else can look at it in due time.
> Usually the tests run at 100%, but sometimes they don't.
> If you really want the build, then you can skip the tests (it is just
> one failure which may not hurt you *right* now):
> mvn -Dmaven.test.skip=true install
> Martijn
> On 5/25/07, Oleg Taranenko <ot...@key-software.com> wrote:
>> Hi, all
>>
>> just now I checkout the last version of the Wicket from the scratch
>> https://svn.apache.org/repos/asf/incubator/wicket/trunk
>>
>> mvn package (and mvn install) failed:
>>
>> [INFO] ------------------------------------------------------------------------
>> [ERROR] BUILD ERROR
>> [INFO] ------------------------------------------------------------------------
>> [INFO] There are test failures.
>> [INFO] ------------------------------------------------------------------------
>> [INFO] For more information, run Maven with the -e switch
>> [INFO] ------------------------------------------------------------------------
>> [INFO] Total time: 23 seconds
>> [INFO] Finished at: Fri May 25 14:19:51 CEST 2007
>> [INFO] Final Memory: 14M/35M
>> [INFO] ------------------------------------------------------------------------
>>
>> Failure is at:
>>
>> === org.apache.wicket.markup.html.basic.SimplePage_12 ===
>> === org.apache.wicket.markup.html.basic.SimplePage_13 ===
>> === org.apache.wicket.markup.html.basic.SimplePage_14 ===
>> [surefire] Tests run: 16, Failures: 1, Errors: 0, Time elapsed: 0,531 sec <<<<<<<< FAILURE !!
>> [surefire] Running org.apache.wicket.markup.html.basic.SimpleResponsePageClassTest
>> [surefire] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,047 sec
>> [surefire] Running org.apache.wicket.markup.html.border.BoxBorderTest
>> === org.apache.wicket.markup.html.border.BoxBorderTestPage_1 ===
>> === org.apache.wicket.markup.html.border.BoxBorderTestPage_2 ===
>>
>>
>> What do I wrong?
>>
>> Thanks
>>
>>
>> Newbie in wicket,
>> Oleg
>>
>>
>>
--
Mit freundlichen Grüßen
Oleg Taranenko
mailto:otaranenko@key-software.com
Re: Build Failed
Posted by Eelco Hillenius <ee...@gmail.com>.
> When you comment such a failing test, then at the very least add the
> class and method to the issue. Otherwise it will be HELL to find the
> test again. Also, ensure that the method is commented with the JIRA
> issue number.
The test was already mentioned in the JIRA issue and of course I added
a TODO with a reference to the JIRA issue in the test.
> I agree that having dirty laundry for weeks gives a very bad smell,
> but that doesn't mean the laundry should be thrown away or completely
> hidden from sight.
Sure. But it isn't as there is a JIRA issue for it.
> Submitting a failing unit test is not only a way to get attention: I
> can invest time to create unit tests that fail, but I can't always
> solve the problem or have the time to solve it (creating a unit test
> that fails for a particular bug is *HARD* and time consuming). So I
> see it also as a way to contribute.
Sure, but still unless they are intended to be fixed within one or two
days, they should not block further builds unless the issue is really,
really grave (in which case they should be marked blockers and in
which case I would be fine with keeping the tests active).
> Also, please note that when we move to JDK 1.5, we can put this
> discussion to rest, as we can annotate our tests to not run (JUnit
> 4.x). They will then be reported as skipped tests and not end up in
> oblivion. TestNG is also a possibility, but I overheard that the maven
> surefire plugin is not up to par.
That's perfect news. Exactly what we need in such cases.
Eelco
Re: Build Failed
Posted by Mark Derricutt <ma...@talios.com>.
Regarding the TestNG issues with Maven - Surefire 2.4 is being worked out
which returns full support of TestNG 5.x+ support to maven - and will also
provide full support for all TestNG functionality such as custom
reports/listeners. Not sure of the timeframe for 2.4 thou. Hopefully its
sooner than later.
On 5/29/07, Martijn Dashorst <ma...@gmail.com> wrote:
>
> I think JUnit 4 is the way to, *after* we ship 1.3. Though I don't
> mind checking out TestNG too for that release.
>
>
Re: Build Failed
Posted by Martijn Dashorst <ma...@gmail.com>.
I think JUnit 4 is the way to, *after* we ship 1.3. Though I don't
mind checking out TestNG too for that release.
Martijn
On 5/29/07, Timo Rantalaiho <Ti...@ri.fi> wrote:
> On Tue, 29 May 2007, Martijn Dashorst wrote:
> > Also, please note that when we move to JDK 1.5, we can put this
> > discussion to rest, as we can annotate our tests to not run (JUnit
> > 4.x). They will then be reported as skipped tests and not end up in
> > oblivion. TestNG is also a possibility, but I overheard that the maven
> > surefire plugin is not up to par.
>
> With JDK 1.4, you can separate different kinds of tests with
> a naming convention, and then run name-based, dynamic suites
> with DirectorySuiteBuilder from JUnit extensions. We have
> used this approach a lot.
>
> Then there would be one suite that would be run by default
> (this can be set in surefire settings) and that should
> always pass 100 %, and another suite for developers, which
> would also include "TestBug" or some such suffix that would
> be used for temporarily failing tests.
>
> This is also handy for separating slow-running tests from
> quick tests (though as much as possible should be covered by
> quick tests anyway).
>
> JUnit 4 / TestNG test groups can be used to do this a lot
> more elegantly.
>
> - Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>
--
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org
Re: Build Failed
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Tue, 29 May 2007, Martijn Dashorst wrote:
> Also, please note that when we move to JDK 1.5, we can put this
> discussion to rest, as we can annotate our tests to not run (JUnit
> 4.x). They will then be reported as skipped tests and not end up in
> oblivion. TestNG is also a possibility, but I overheard that the maven
> surefire plugin is not up to par.
With JDK 1.4, you can separate different kinds of tests with
a naming convention, and then run name-based, dynamic suites
with DirectorySuiteBuilder from JUnit extensions. We have
used this approach a lot.
Then there would be one suite that would be run by default
(this can be set in surefire settings) and that should
always pass 100 %, and another suite for developers, which
would also include "TestBug" or some such suffix that would
be used for temporarily failing tests.
This is also handy for separating slow-running tests from
quick tests (though as much as possible should be covered by
quick tests anyway).
JUnit 4 / TestNG test groups can be used to do this a lot
more elegantly.
- Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
Re: Build Failed
Posted by Johan Compagner <jc...@gmail.com>.
why would i do a text search?
and yes i hate command line :)
i just want TODO or TASK marker then its very easy to find in eclipse
johan
On 5/29/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
>
> * Martijn Dashorst:
>
> > When you comment such a failing test, then at the very least add the
> > class and method to the issue. Otherwise it will be HELL to find the
> > test again. Also, ensure that the method is commented with the JIRA
> > issue number.
>
> That's why I suggested to rename testXXX() to bugTestXXX(), see
> how it's easy to find it:
>
> $ cd wicket
> $ grep -rs bugTest src/test/java
>
> Whereas only commenting it makes it impossible to find it again.
> Am I the only command-line addict here? Come on you can also
> do a text search in Eclipse can't you?
> --
> Jean-Baptiste Quenot
> aka John Banana Qwerty
> http://caraldi.com/jbq/
>
Re: Build Failed
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Martijn Dashorst:
> When you comment such a failing test, then at the very least add the
> class and method to the issue. Otherwise it will be HELL to find the
> test again. Also, ensure that the method is commented with the JIRA
> issue number.
That's why I suggested to rename testXXX() to bugTestXXX(), see
how it's easy to find it:
$ cd wicket
$ grep -rs bugTest src/test/java
Whereas only commenting it makes it impossible to find it again.
Am I the only command-line addict here? Come on you can also
do a text search in Eclipse can't you?
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Build Failed
Posted by Eelco Hillenius <ee...@gmail.com>.
That's a pretty cool idea.
Eelco
On 5/28/07, Mark Derricutt <ma...@talios.com> wrote:
> Regarding the TestNG side of things - a little hack I whipped up awhile ago
> for this sort of thing is here:
>
> http://www.talios.com/automated_test_regression_reporting_with_testng_and_jira.htm
>
> Whilst not ideal in its current form (repeated jira comments on each
> failure) I find the idea quite useful, although I'm not running it against
> my $work code just yet.
>
> A TestNG listener watches for failed tests, and if the test has an
> associated @RelatedIssue annotation the JIRA ticket is commented with the
> failure stacktrace. Currently in my code I'm just added @RelatedIssue
> annotations whenever I add @Test's that relate to a particular issue.
>
> Mark
>
> On 5/29/07, Martijn Dashorst <ma...@gmail.com> wrote:
> >
> > Also, please note that when we move to JDK 1.5, we can put this
> > discussion to rest, as we can annotate our tests to not run (JUnit
> > 4.x). They will then be reported as skipped tests and not end up in
> > oblivion. TestNG is also a possibility, but I overheard that the maven
> > surefire plugin is not up to par.
> >
>
Re: Build Failed
Posted by Mark Derricutt <ma...@talios.com>.
Regarding the TestNG side of things - a little hack I whipped up awhile ago
for this sort of thing is here:
http://www.talios.com/automated_test_regression_reporting_with_testng_and_jira.htm
Whilst not ideal in its current form (repeated jira comments on each
failure) I find the idea quite useful, although I'm not running it against
my $work code just yet.
A TestNG listener watches for failed tests, and if the test has an
associated @RelatedIssue annotation the JIRA ticket is commented with the
failure stacktrace. Currently in my code I'm just added @RelatedIssue
annotations whenever I add @Test's that relate to a particular issue.
Mark
On 5/29/07, Martijn Dashorst <ma...@gmail.com> wrote:
>
> Also, please note that when we move to JDK 1.5, we can put this
> discussion to rest, as we can annotate our tests to not run (JUnit
> 4.x). They will then be reported as skipped tests and not end up in
> oblivion. TestNG is also a possibility, but I overheard that the maven
> surefire plugin is not up to par.
>
Re: Build Failed
Posted by Martijn Dashorst <ma...@gmail.com>.
When you comment such a failing test, then at the very least add the
class and method to the issue. Otherwise it will be HELL to find the
test again. Also, ensure that the method is commented with the JIRA
issue number.
I agree that having dirty laundry for weeks gives a very bad smell,
but that doesn't mean the laundry should be thrown away or completely
hidden from sight.
Submitting a failing unit test is not only a way to get attention: I
can invest time to create unit tests that fail, but I can't always
solve the problem or have the time to solve it (creating a unit test
that fails for a particular bug is *HARD* and time consuming). So I
see it also as a way to contribute.
Also, please note that when we move to JDK 1.5, we can put this
discussion to rest, as we can annotate our tests to not run (JUnit
4.x). They will then be reported as skipped tests and not end up in
oblivion. TestNG is also a possibility, but I overheard that the maven
surefire plugin is not up to par.
Martijn
--
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org
Re: Build Failed
Posted by Eelco Hillenius <ee...@gmail.com>.
Look, having a failing unit test only works when it is indeed fixed
ASAP. This is a known issue for a least a few days now, and there
isn't even any serious discussion on how this might be fixed, so atm a
quick fix seems unlikely. Also, though the problem can be anoying,
it's not a show stopper in my book. The issue[1] was filed as minor,
though I just bumped it up to major as it is a structural (low level)
framework bug which imo are more serious bugs in specific components.
I'm commenting the failing unit test now, so that it doesn't block the
rest of our development. I don't disagree with committing a failing
unit test every now and then to get some attention, but an issue
related to that either should be fixed within one or two days, or the
test should be commented and the issue marked as a known one, possibly
bumbing up the priority to make sure no-one forgets it.
Eelco
[1] https://issues.apache.org/jira/browse/WICKET-590
On 5/28/07, Martijn Dashorst <ma...@gmail.com> wrote:
> On 5/28/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
> > Mmm actually I don't really agree, making the build fail should
> > not be intentional. We could have some convention like for
> > example naming the failing unit test methods after bugTestXXX()
> > instead of testXXX() to make it obvious that the test does not run
> > and that there is a bug.
>
> I really disagree with this: it is already hard to make a bug
> reproducable. Often the person reproducing the bug does not know how
> to solve it. The person having *time* to solve it, usually doesn't
> have time to build a test case for it.
>
> Having failing test cases on trunk is obviously not good, but it is
> better than not having testcases, or testcases that don't get run
> (which is what you are proposing).
>
> If you commit a failing testcase, it is necessary to make sure dev@ is
> notified, so people know it is not their fault and that it is
> intentional/necessary.
>
> It is also necessary to fix the thing pronto, but if it were that
> easy, the fix would've been committed together with the test case,
> wouldn't it?
>
> Trunk is for development: at any given time the test can fail. They
> just need to get fixed quickly. Note that this is not an excuse for
> not running and fixing the unit tests before a commit.
>
> Martijn
>
> --
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.6 contains a very important fix. Download Wicket now!
> http://wicketframework.org
>
Re: Build Failed
Posted by Martijn Dashorst <ma...@gmail.com>.
On 5/28/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
> Mmm actually I don't really agree, making the build fail should
> not be intentional. We could have some convention like for
> example naming the failing unit test methods after bugTestXXX()
> instead of testXXX() to make it obvious that the test does not run
> and that there is a bug.
I really disagree with this: it is already hard to make a bug
reproducable. Often the person reproducing the bug does not know how
to solve it. The person having *time* to solve it, usually doesn't
have time to build a test case for it.
Having failing test cases on trunk is obviously not good, but it is
better than not having testcases, or testcases that don't get run
(which is what you are proposing).
If you commit a failing testcase, it is necessary to make sure dev@ is
notified, so people know it is not their fault and that it is
intentional/necessary.
It is also necessary to fix the thing pronto, but if it were that
easy, the fix would've been committed together with the test case,
wouldn't it?
Trunk is for development: at any given time the test can fail. They
just need to get fixed quickly. Note that this is not an excuse for
not running and fixing the unit tests before a commit.
Martijn
--
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org
Re: Build Failed
Posted by Al Maw <wi...@almaw.com>.
Jean-Baptiste Quenot wrote:
> Mmm actually I don't really agree, making the build fail should
> not be intentional. We could have some convention like for
> example naming the failing unit test methods after bugTestXXX()
> instead of testXXX() to make it obvious that the test does not run
> and that there is a bug.
Sorry for this, this is probably my fault. ;-)
Having failing unit tests for days on end is definitely bad - it
massively reduces the utility of your continuous integration server.
I originally intended this to be fixed pretty rapidly, hence the
immediate tender for ideas on how to fix it on IRC and the dev mailing
list. Once it wasn't, I should have commented the test out and made
appropriate notes on the JIRA issue.
We have a bug tracker to work out what bugs need fixing before we do a
release, so commenting things doesn't shove them into "a big black hole
where no one is looking at it". It's a bug we currently have scheduled
for fixing before we push 1.3.0-rc1 out. That most definitely makes it
on the immediate radar.
Regards,
Al
--
Alastair Maw
Wicket-biased blog at http://herebebeasties.com
Re: Build Failed
Posted by Johan Compagner <jc...@gmail.com>.
but if you do that (give it that name) the build works right?
so then the method isn't executed and its in the deep black hole where
nobody is looking at it again..
failures can happen and if they don't show in the unit test i run (or bamboo
runs)
then i will not notice them and never do anything about it.
about the current one. i think i will comment it out let one build pass and
then enable the failure test
again so that we do have a build for people that are testing against the
snapshots
johan
On 5/28/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
>
> * Martijn Dashorst:
>
> > In Wicket development (on the core project), the unit tests
> > sometimes just don't run for a couple of days because they are
> > used as a method of communication: someone knows how to
> > reproduce a bug but doesn't know how to fix it. The unit test
> > exposing the bug is then committed, so that someone else can
> > look at it in due time.
>
> Mmm actually I don't really agree, making the build fail should
> not be intentional. We could have some convention like for
> example naming the failing unit test methods after bugTestXXX()
> instead of testXXX() to make it obvious that the test does not run
> and that there is a bug.
> --
> Jean-Baptiste Quenot
> aka John Banana Qwerty
> http://caraldi.com/jbq/
>
Re: Build Failed
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Martijn Dashorst:
> In Wicket development (on the core project), the unit tests
> sometimes just don't run for a couple of days because they are
> used as a method of communication: someone knows how to
> reproduce a bug but doesn't know how to fix it. The unit test
> exposing the bug is then committed, so that someone else can
> look at it in due time.
Mmm actually I don't really agree, making the build fail should
not be intentional. We could have some convention like for
example naming the failing unit test methods after bugTestXXX()
instead of testXXX() to make it obvious that the test does not run
and that there is a bug.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Build Failed
Posted by Al Maw <wi...@almaw.com>.
Martijn Dashorst wrote:
> You don't do anything wrong.
>
> In Wicket development (on the core project), the unit tests sometimes
> just don't run for a couple of days because they are used as a method
> of communication: someone knows how to reproduce a bug but doesn't
> know how to fix it. The unit test exposing the bug is then committed,
> so that someone else can look at it in due time.
FWIW, this is http://issues.apache.org/jira/browse/WICKET-590
Al
Re: Build Failed
Posted by Martijn Dashorst <ma...@gmail.com>.
You don't do anything wrong.
In Wicket development (on the core project), the unit tests sometimes
just don't run for a couple of days because they are used as a method
of communication: someone knows how to reproduce a bug but doesn't
know how to fix it. The unit test exposing the bug is then committed,
so that someone else can look at it in due time.
Usually the tests run at 100%, but sometimes they don't.
If you really want the build, then you can skip the tests (it is just
one failure which may not hurt you *right* now):
mvn -Dmaven.test.skip=true install
Martijn
On 5/25/07, Oleg Taranenko <ot...@key-software.com> wrote:
> Hi, all
>
> just now I checkout the last version of the Wicket from the scratch
> https://svn.apache.org/repos/asf/incubator/wicket/trunk
>
> mvn package (and mvn install) failed:
>
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 23 seconds
> [INFO] Finished at: Fri May 25 14:19:51 CEST 2007
> [INFO] Final Memory: 14M/35M
> [INFO] ------------------------------------------------------------------------
>
> Failure is at:
>
> === org.apache.wicket.markup.html.basic.SimplePage_12 ===
> === org.apache.wicket.markup.html.basic.SimplePage_13 ===
> === org.apache.wicket.markup.html.basic.SimplePage_14 ===
> [surefire] Tests run: 16, Failures: 1, Errors: 0, Time elapsed: 0,531 sec <<<<<<<< FAILURE !!
> [surefire] Running org.apache.wicket.markup.html.basic.SimpleResponsePageClassTest
> [surefire] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,047 sec
> [surefire] Running org.apache.wicket.markup.html.border.BoxBorderTest
> === org.apache.wicket.markup.html.border.BoxBorderTestPage_1 ===
> === org.apache.wicket.markup.html.border.BoxBorderTestPage_2 ===
>
>
> What do I wrong?
>
> Thanks
>
>
> Newbie in wicket,
> Oleg
>
>
>
--
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org