Re: Re: Re: Re: [Cruisecontrol-user] junit error on 2.4.1

[Jeffrey F. <jef...@gm...>]

I would just delete the offending test file:
net.sourceforge.cruisecontrol.util.threadpool.ThreadQueueTest.java

Jtf

On 3/16/06, Juergen Biebl <Jue...@ms...> wrote:
>
> Can you please tell me how I can exclude just this two test cases and not=
 skip all tests?
>
>
> "Jeffrey Fredrick" <jef...@gm...>
> Gesendet von: cru...@li...
>
>
> 16.03.2006 10:33
>
>
> An
> "Juergen Biebl" <Jue...@ms...>
>
>
> Kopie
> cru...@li...
>
>
> Thema Re: Re: Re: [Cruisecontrol-user] junit error on 2.4.1
>
> Ah, that one, the expected <1> but was <0> happens a lot and we really
>  should either rewrite the test to make it more robust or just scrap
>  it.  It was the testIsNotIdle one that had me worried as I hadn't seen
>  that before, but it is likely it is just not quite as fragile as the
>  testExecution one.
>
>  I don't think either represents a real bug, just bad tests.
>
>  Jtf
>
>  On 3/16/06, Juergen Biebl <Jue...@ms...> wrote:
>  >
>  >
>  > No I had no problem with the build queue by now.
>  >
>  > The tests does not fail constantly - I tried to build 15 times and the=
 test failed 12 times.
>  >
>  > And it is not always the same test that failes, e.g.:
>  >     [junit] Testcase: testExecution(net.sourceforge.cruisecontrol.util=
.threadpool.ThreadQueueTest):     FAILED
>  >     [junit] expected:<1> but was:<0>
>  >     [junit] junit.framework.AssertionFailedError: expected:<1> but was=
:<0>
>  >     [junit]     at net.sourceforge.cruisecontrol.util.threadpool.Threa=
dQueueTest.testExecution(ThreadQueueTest.java:182)
>  >
>  >     [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native=
 Method)
>  >     [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeM=
ethodAccessorImpl.java(Compiled Code))
>  >     [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeM=
ethodAccessorImpl.java(Compiled Code))
>  >     [junit]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Del=
egatingMethodAccessorImpl.java(Compiled Code))
>  >
>  >
>  > This behaviour also happens under Solaris 5.8
>  >
>  > Never had problems compiling in Windows environment  (Windows XP).
>  >
>  > Could this be an odd Unix problem?
>  >
>  >
>  > J=FCrgen
>  >
>  > "Jeffrey Fredrick" <jef...@gm...>
>  > Gesendet von: cru...@li...
>  >
>  >
>  > 16.03.2006 09:51
>  >
>  >
>  > An
>  > "Juergen Biebl" <Jue...@ms...>
>  >
>  >
>  > Kopie
>  > cruise-control <cru...@li...>
>  >
>  >
>  > Thema Re: Re: [Cruisecontrol-user] junit error on 2.4.1
>  >
>  >
>  > Hmm, and that particular test fails consistently for you?  I'd almost
>  >  worry that would be a bug w/our code on the AIX jvm...  Ever have odd
>  >  behavior w/the build queue?
>  >
>  >  Jtf
>  >
>  >  On 3/15/06, Juergen Biebl <Jue...@ms...> wrote:
>  >  >
>  >  > I have a similar problem with junit error on CC2.4.0
>  >  >
>  >  >     [junit] ------------- Standard Output ---------------
>  >  >     [junit]  setup down =3D 107
>  >  >     [junit]  tear down =3D 10050
>  >  >     [junit]  setup down =3D 100
>  >  >     [junit]  tear down =3D 10039
>  >  >     [junit] ------------- ---------------- ---------------
>  >  >     [junit] Testcase: testIsNotIdle(net.sourceforge.cruisecontrol.u=
til.threadpool.ThreadQueueTest):     FAILED
>  >  >     [junit] null
>  >  >     [junit] junit.framework.AssertionFailedError
>  >  >     [junit]     at net.sourceforge.cruisecontrol.util.threadpool.Th=
readQueueTest.testIsNotIdle(ThreadQueueTest.java:81)
>  >  >
>  >  >     [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Nat=
ive Method)
>  >  >
>  >  >     [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke(Nati=
veMethodAccessorImpl.java(Compiled Code))
>  >  >     [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke(Nati=
veMethodAccessorImpl.java(Compiled Code))
>  >  >     [junit]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(=
DelegatingMethodAccessorImpl.java(Compiled Code))
>  >  >
>  >  > Environment:
>  >  > OS: AIX 5.3
>  >  > JAVA: java version "1.4.2"
>  >  >              Java(TM) 2 Runtime Environment, Standard Edition (buil=
d 1.4.2)
>  >  >
>  >  > There must be something odd with the testcases. The workaround for =
me was to call
>  >  > build.sh  jar
>  >  > so no unit tests are executed.
>  >  >

--

http://www.developertesting.com/