commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [lang] test failures
Date Mon, 05 Mar 2012 17:16:53 GMT
On 5 March 2012 17:11, sebb <sebbaz@gmail.com> wrote:
> On 5 March 2012 16:53, Jörg Schaible <Joerg.Schaible@scalaris.com> wrote:
>> sebb wrote:
>>
>>> On 5 March 2012 15:09, Benedikt Ritter <bene@systemoutprintln.de> wrote:
>>>> Am 05.03.2012 16:03, schrieb Benedikt Ritter:
>>>>
>>>>> Am 04.03.2012 12:26, schrieb Jörg Schaible:
>>>>>>
>>>>>> Benedikt Ritter wrote:
>>>>>>
>>>>>>> Just out of curiosity ;) Are there plans to do anything about
that? I
>>>>>>> guess it would be desirable if the component compiles on Java
7 as
>>>>>>> well. I still don't know if things are broken when compiling
with Java
>>>>>>> 7 or if the errors are just caused by API changes in Java 7.
If the
>>>>>>> latter, we could use JUnit's Theories runner and write an assumeTrue()
>>>>>>> statement for those test cases, that checks what Java version
the test
>>>>>>> is running with.
>>>>>>
>>>>>>
>>>>>> I am quite sure I voted on lang3 and that means I also tested it
with
>>>>>> Java
>>>>>> 7. Actually I can build lang3 HEAD with Java 7:
>>>>>
>>>>>
>>>>> sorry, I'm not sure if I got you right. Are you saying that the problems
>>>>> Gary was experiencing are not a result of Java 7 usage? Then we should
>>>>> investigate further.
>>>>>
>>>>
>>>> I just checked out HEAD and run mvn test with my setup:
>>>>
>>>> D:\Entwicklung\workspaces\commons\lang>mvn -version
>>>> Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
>>>> Maven home: D:\Entwicklung\maven\3.0.3
>>>> Java version: 1.7.0_01, vendor: Oracle Corporation
>>>> Java home: D:\Entwicklung\Java\jdk1.7.0_01\jre
>>>> Default locale: de_DE, platform encoding: Cp1252
>>>> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>>>>
>>>> I got the same result as Jörg. Gary, maybe you should have another look
>>>> at that issue?
>>>>
>>>> Regards,
>>>> Benedikt
>>>
>>> The tests also fail in Gump.
>>> I've tweaked the assertion to try and help a bit.
>>>
>>> Had a possibly similar situation in JMeter recently; only the Gump build
>>> failed. Turned out that the tests were being run in a different order by
>>> the Gump JVM; this revealed a test bug which was failing to clear up data
>>> from a previous test.
>>
>>
>> We might set the runOrder to "random" in the surefire plugin. This helps to
>> ensure that tests will not have unwanted side effects.
>
> Good idea; I'll add that.

On second thoughts, that won't help if the problem is the order of
tests *within* a test class (as was the case for JMeter).

> I've just added some checks to see that the data is not present before
> the test starts.
>
> BTW the JMeter test used Maven; it was the JVM which permuted the test order.
>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message