Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.7.4
-
Component/s: Core
-
Labels:None
-
Environment:Hideuname -a
Linux somehost 3.2.0-35-generic-pae #55-Ubuntu SMP Wed Dec 5 18:04:39 UTC 2012 i686 i686 i386 GNU/Linux
java -version
java version "1.7.0_09"
OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-0ubuntu1~12.04.1)
OpenJDK Server VM (build 23.2-b09, mixed mode)
Showuname -a Linux somehost 3.2.0-35-generic-pae #55-Ubuntu SMP Wed Dec 5 18:04:39 UTC 2012 i686 i686 i386 GNU/Linux java -version java version "1.7.0_09" OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-0ubuntu1~12.04.1) OpenJDK Server VM (build 23.2-b09, mixed mode)
-
Number of attachments :
Description
Unit test StepsBehaviour.shouldReportFailuresInBeforeAndAfterMethods is broken when run on JDK 7 (see stacktrace attached). With JDK 6 this error doesn't occur.
What actually breaks the test is that methods annotated with @BeforeScenario are picked in different order for the two JDK versions. This is caused by the fact that java.lang.Class.getMethods() returns methods in no particular order as clearly stated in its javadoc and probably its implementation has been changed.
The question is whether it's enough just to fix the test to enforce the order or this issue affects the framework more deeply and additional measures are needed.
Activity
Can't reproduce it on Mac - Java version: 1.7.0_09, vendor: Oracle Corporation
Yes, the root of the issue is the order in which the Class.getMethods() returns the methods.
If you could provide a patch to fix the test on OpenJDK, it'd be appreciated.
Mauro Talevi
added a comment - Can't reproduce it on Mac - Java version: 1.7.0_09, vendor: Oracle Corporation
Yes, the root of the issue is the order in which the Class.getMethods() returns the methods.
If you could provide a patch to fix the test on OpenJDK, it'd be appreciated.
Sure, I'll provide the patch once I get used to github and provide a link here as decribed in this article: http://jbehave.org/reference/preview/how-to-contribute.html
Volodymyr Sobotovych
added a comment - Sure, I'll provide the patch once I get used to github and provide a link here as decribed in this article: http://jbehave.org/reference/preview/how-to-contribute.html I've pushed the fix to my fork. Please review and let me know if you have any questions: https://github.com/wheleph/jbehave-core/commit/29a132272809c7d641477a6a81f483f7477cd6e0
Also created a pull request on github with those changes
Volodymyr Sobotovych
added a comment - - edited I've pushed the fix to my fork. Please review and let me know if you have any questions: https://github.com/wheleph/jbehave-core/commit/29a132272809c7d641477a6a81f483f7477cd6e0
Also created a pull request on github with those changes Pulled with thanks.
Mauro Talevi
added a comment - Pulled with thanks. Mauro Talevi
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Fix Version/s | 3.7.5 [ 18997 ] | |
| Resolution | Fixed [ 1 ] |
Mauro Talevi
made changes -
| Summary | StepsBehaviour.shouldReportFailuresInBeforeAndAfterMethods broken for OpenJDK 7 | StepsBehaviour test broken for OpenJDK 7 |
Mauro Talevi
made changes -
| Fix Version/s | 3.8 [ 19104 ] |
I think I had a similar problem in another test class that assumed a specific order for the list of methods where I changed the unit test to look at all members of the array.
I think it would be correct just to fix the test as well, since there are no assumptions made on the order of methods when you actually run your methods (or there shouldn't be at least).