[jbehave-dev] [jira] (JBEHAVE-1046) JBehave exits immaturely
Title: Message Title Mohsen Hariri created an issue JBehave / JBEHAVE-1046 JBehave exits immaturely Issue Type: Bug Affects Versions: 3.9.4 Assignee: Unassigned Components: Core Created: 04/Sep/14 3:28 AM Environment: Mac OSX Priority: Major Reporter: Mohsen Hariri When I run a story, JBehave exits without waiting for the story results. The same stories work perfectly in version 3.9.3. Add Comment
[jbehave-dev] [jira] (JBEHAVE-1046) JBehave exits immaturely
Title: Message Title
Mohsen Hariri commented on an issue
Re: JBehave exits immaturely
I tracked down the problem and it resides in jbehave-core/src/main/java/org/jbehave/core/embedder/StoryManager.java:
public void waitUntilAllDoneOrFailed(BatchFailures failures) {
boolean allDone = false;
while (!allDone) {
allDone = true;
for (RunningStory runningStory : runningStories.values()) {
if ( runningStory.isStarted() ){
Story story = runningStory.getStory();
Future future = runningStory.getFuture();
if (!future.isDone()) {
allDone = false;
In the above code, the if ( runningStory.isStarted() ){ does not have any else, so if the stories have not yet started, allDone is left true and JBehave exits without waiting for the stories to finish running.
Add Comment
JBehave / JBEHAVE-1046
JBehave exits immaturely
When I run a story, JBehave exits without waiting for the story results. The same stories work perfectly in version 3.9.3.
This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c)
[jbehave-dev] [jira] (JBEHAVE-1045) Support for class-based AOP in step classes in Spring
Title: Message Title
Francisco Lozano edited a comment on an issue
Re: Support for class-based AOP in step classes in Spring
Please take a look at https://github.com/jbehave/jbehave-core/pull/67 . However:test `shouldBuildCandidateStepsFromAnnotationsUsingSpring` still fails, and to be honest I think it's due to the test being wrong:The configuration class for that file looks like:{CODE}@Configure()@UsingSpring(resources = { "org/jbehave/core/configuration/spring/configuration.xml","org/jbehave/core/steps/spring/steps.xml", "org/jbehave/core/steps/spring/steps-with-dependency.xml" })private static class AnnotatedUsingSpring {}{CODE}which is mixing both steps.xml and steps-with-dependency.xml. However, FooStepsWithDependency inherits from FooSteps, a condition I think would not work (because of repeated definitions of the same steps in two step classes).Failure of that test is like:{CODE}java.lang.AssertionError: Expected: an instance of org.jbehave.core.steps.spring.SpringStepsFactoryBehaviour$FooStepsWithDependency but: is a org.jbehave.core.steps.spring.SpringStepsFactoryBehaviour$FooSteps at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8) at org.jbehave.core.configuration.spring.SpringAnnotationBuilderBehaviour.assertThatStepsInstancesAre(SpringAnnotationBuilderBehaviour.java:141) at org.jbehave.core.configuration.spring.SpringAnnotationBuilderBehaviour.shouldBuildCandidateStepsFromAnnotationsUsingSpring(SpringAnnotationBuilderBehaviour.java:111) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192){CODE}It depends purely on the order the getBeanDefinitionNames() is returning the two beans (fooStep and fooStepWithDependency).
[jbehave-dev] [jira] (JBEHAVE-1045) Support for class-based AOP in step classes in Spring
Title: Message Title
Francisco Lozano commented on an issue
Re: Support for class-based AOP in step classes in Spring
Please look at https://github.com/jbehave/jbehave-core/pull/67 .
However: test `shouldBuildCandidateStepsFromAnnotationsUsingSpring` still fails, and to be honest I think it's due to the test being wrong: The configuration class for that file looks like:
@Configure()
@UsingSpring(resources = { "org/jbehave/core/configuration/spring/configuration.xml",
"org/jbehave/core/steps/spring/steps.xml", "org/jbehave/core/steps/spring/steps-with-dependency.xml" })
private static class AnnotatedUsingSpring {
}
which is mixing both steps.xml and steps-with-dependency.xml. However, FooStepsWithDependency inherits from FooSteps, a condition I think would not work (because of repeated definitions of the same steps in two step classes).
Failure of that test is like:
java.lang.AssertionError:
Expected: an instance of org.jbehave.core.steps.spring.SpringStepsFactoryBehaviour$FooStepsWithDependency
but: is a org.jbehave.core.steps.spring.SpringStepsFactoryBehaviour$FooSteps
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
at org.jbehave.core.configuration.spring.SpringAnnotationBuilderBehaviour.assertThatStepsInstancesAre(SpringAnnotationBuilderBehaviour.java:141)
at org.jbehave.core.configuration.spring.SpringAnnotationBuilderBehaviour.shouldBuildCandidateStepsFromAnnotationsUsingSpring(SpringAnnotationBuilderBehaviour.java:111)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
[jbehave-dev] [jira] (JBEHAVE-1045) Support for class-based AOP in step classes in Spring
Title: Message Title
Francisco Lozano edited a comment on an issue
Re: Support for class-based AOP in step classes in Spring
Please take a look at https://github.com/jbehave/jbehave-core/pull/67 . However:test `shouldBuildCandidateStepsFromAnnotationsUsingSpring` still fails, and to be honest I think it's due to the test being wrong:The configuration class for that file used in this test looks like:{CODE}@Configure()@UsingSpring(resources = { "org/jbehave/core/configuration/spring/configuration.xml","org/jbehave/core/steps/spring/steps.xml", "org/jbehave/core/steps/spring/steps-with-dependency.xml" })private static class AnnotatedUsingSpring {}{CODE}which is mixing both steps.xml and steps-with-dependency.xml. However, FooStepsWithDependency inherits from FooSteps, a condition I think would not work (because of repeated definitions of the same steps in two step classes).Failure of that test is like:{CODE}java.lang.AssertionError: Expected: an instance of org.jbehave.core.steps.spring.SpringStepsFactoryBehaviour$FooStepsWithDependency but: is a org.jbehave.core.steps.spring.SpringStepsFactoryBehaviour$FooSteps at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8) at org.jbehave.core.configuration.spring.SpringAnnotationBuilderBehaviour.assertThatStepsInstancesAre(SpringAnnotationBuilderBehaviour.java:141) at org.jbehave.core.configuration.spring.SpringAnnotationBuilderBehaviour.shouldBuildCandidateStepsFromAnnotationsUsingSpring(SpringAnnotationBuilderBehaviour.java:111) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192){CODE}It depends purely on the order the getBeanDefinitionNames() is returning the two beans (fooStep and fooStepWithDependency).
[jbehave-dev] [jira] (JBEHAVE-1045) Support for class-based AOP in step classes in Spring
Title: Message Title
Francisco Lozano edited a comment on an issue
Re: Support for class-based AOP in step classes in Spring
Please take a look at https://github.com/jbehave/jbehave-core/pull/67 . However:test `shouldBuildCandidateStepsFromAnnotationsUsingSpring` still fails, and to be honest I think it's due to the test being wrong:The configuration class used in this test looks like:{CODE}@Configure()@UsingSpring(resources = { "org/jbehave/core/configuration/spring/configuration.xml","org/jbehave/core/steps/spring/steps.xml", "org/jbehave/core/steps/spring/steps-with-dependency.xml" })private static class AnnotatedUsingSpring {}{CODE}which is mixing both steps.xml and steps-with-dependency.xml. However, FooStepsWithDependency inherits from FooSteps, a condition I think would not work (because of repeated definitions of the same steps in two step classes).Failure of that test is like:{CODE}java.lang.AssertionError: Expected: an instance of org.jbehave.core.steps.spring.SpringStepsFactoryBehaviour$FooStepsWithDependency but: is a org.jbehave.core.steps.spring.SpringStepsFactoryBehaviour$FooSteps at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8) at org.jbehave.core.configuration.spring.SpringAnnotationBuilderBehaviour.assertThatStepsInstancesAre(SpringAnnotationBuilderBehaviour.java:141) at org.jbehave.core.configuration.spring.SpringAnnotationBuilderBehaviour.shouldBuildCandidateStepsFromAnnotationsUsingSpring(SpringAnnotationBuilderBehaviour.java:111) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192){CODE}It depends purely on the order the getBeanDefinitionNames() is returning the two beans (fooStep and fooStepWithDependency). I think it'd be better to explicitly fail on this by using context.getBean(Class type), which would fail because more than one bean would match that type I think:{CODE}public Object createInstanceOfType(Class type) {try {return context.getBean(type);} catch (NoSuchBeanDefinitionException e) {throw new StepsInstanceNotFound(type, this);}}{CODE}
[jbehave-dev] [jira] (JBEHAVE-1045) Support for class-based AOP in step classes in Spring
Title: Message Title Mauro Talevi commented on an issue Re: Support for class-based AOP in step classes in Spring Thanks for the pull request. It looks good at first sight. Will try to pull shortly. As for the test, you are right that it should not rely on the order. Add Comment JBehave / JBEHAVE-1045 Support for class-based AOP in step classes in Spring When I add @EnableAspectJAutoProxy in my spring setup, with the bundled steps factory, my step beans can't be found. I've done my own steps factory... it assumes the use of a specific type annotation on the step classes, to make it more clear which beans to explore, but that can be removed in a more general case. Here it's how it looks like (WIP): ... This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] (JBEHAVE-1046) JBehave exits immaturely
Title: Message Title Mauro Talevi commented on an issue Re: JBehave exits immaturely Can you please provide an example of running stories not being started? The assumption is that at least one story has started. Otherwise, we can add a wait for at least one to start. Add Comment JBehave / JBEHAVE-1046 JBehave exits immaturely When I run a story, JBehave exits without waiting for the story results. The same stories work perfectly in version 3.9.3. This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] (JBEHAVE-1046) JBehave exits immaturely
Title: Message Title Mohsen Hariri commented on an issue Re: JBehave exits immaturely I ran the following story without any Steps implementation: Feature: Login Narrative: In order to use the system, one needs to login and identify herself to the system Scenario: Login page When user browses to http://localhost:1090/ Then the login page appears I had configured the runner to complain about the non-existing implementations: embedder.configuration().usePendingStepStrategy(new FailingUponPendingStep()); Expected behaviour: build should fail with that configuration Actual behaviour: it always succeeded JBehave version: jbehave-ant 3.9.4 More details: I did not get any failures, so I started debugging JBehave. When tracing, sometimes I got the error, so I guessed it was a timing issue. Debugging more and I came into the place I pasted above. Then I used the 3.9.3 version and the build always failed with that version, as expected. Add Comment JBehave / JBEHAVE-1046 JBehave exits immaturely When I run a story, JBehave exits without waiting for the story results. The same stories work perfectly in version 3.9.3.
[jbehave-dev] [jira] (JBEHAVE-1045) Support for class-based AOP in step classes in Spring
Title: Message Title
Francisco Lozano commented on an issue
Re: Support for class-based AOP in step classes in Spring
Thanks!
The test also contains explicit exclusion for steps declaration in interfaces. For example,
public interface FooBarSteps {
@Given("whatever bla bla")
void givenWhateverBlaBla();
}
public class FooBarStepsImpl {
@Override
public void givenWhateverBlaBla() {
}
}
it ensures (same as current behavior) that those are not exposed by the steps factory.
However, I think it'd be great to support them. It would allow JDK Proxies for steps, and would allow separating step interface construction from actual step implementation.
One example use-case would be making it possible to test, with the same stories, two "client libraries" with the same functionality but different interfaces by reimplementing the step classes.
I think the StepsFactory changes needed are simple, but i assume also some other changes would be needed somewhere else (and I haven't explored enough yet to identify).
Add Comment
JBehave / JBEHAVE-1045
Support for class-based AOP in step classes in Spring
When I add @EnableAspectJAutoProxy in my spring setup, with the bundled steps factory, my step beans can't be found. I've done my own steps factory... it assumes the use of a specific type annotation on the step classes, to make it more clear which beans to explore, but that can be removed in a more general case. Here it's how it looks like (WIP): ...
[jbehave-dev] [jira] (JBEHAVE-1045) Support for class-based AOP in step classes in Spring
Title: Message Title
Francisco Lozano edited a comment on an issue
Re: Support for class-based AOP in step classes in Spring
Thanks! The test also contains explicit exclusion for steps declaration in interfaces. For example,{CODE}public interface FooBarSteps { @Given("whatever bla bla") void givenWhateverBlaBla();}public class FooBarStepsImpl {@Overridepublic void givenWhateverBlaBla() {}}{CODE}it ensures (same as current behavior) that those are not exposed by the steps factory.However, I think it'd be great to support them. It would allow JDK Proxies for steps, and would allow separating step interface construction from actual step implementation. One example use-case would be making it possible to test, with the same stories, two "client libraries" with the same functionality but different interfaces APIs, by reimplementing the step classes using each library's API .I think the StepsFactory changes needed are simple, but i assume also some other changes would be needed somewhere else (and I haven't explored enough yet to identify).
Add Comment
JBehave / JBEHAVE-1045
Support for class-based AOP in step classes in Spring
When I add @EnableAspectJAutoProxy in my spring setup, with the bundled steps factory, my step beans can't be found. I've done my own steps factory... it assumes the use of a specific type annotation on the step classes, to make it more clear which beans to explore, but that can be removed in a more general case. Here it's how it looks like (WIP): ...
This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c)
[jbehave-dev] [jira] (JBEHAVE-1045) Support for class-based AOP in step classes in Spring
Title: Message Title Mauro Talevi commented on an issue Re: Support for class-based AOP in step classes in Spring Please raise a different issue for the proxy behaviour Add Comment JBehave / JBEHAVE-1045 Support for class-based AOP in step classes in Spring When I add @EnableAspectJAutoProxy in my spring setup, with the bundled steps factory, my step beans can't be found. I've done my own steps factory... it assumes the use of a specific type annotation on the step classes, to make it more clear which beans to explore, but that can be removed in a more general case. Here it's how it looks like (WIP): ... This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] (JBEHAVE-1047) Support for @Given/@When/@Then annotations in interfaces
Title: Message Title Francisco Lozano created an issue JBehave / JBEHAVE-1047 Support for @Given/@When/@Then annotations in interfaces Issue Type: Improvement Assignee: Unassigned Created: 04/Sep/14 11:06 AM Priority: Major Reporter: Francisco Lozano Add Comment This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] (JBEHAVE-1047) Support for @Given/@When/@Then annotations in interfaces
Title: Message Title
Francisco Lozano updated an issue
JBehave / JBEHAVE-1047
Support for @Given/@When/@Then annotations in interfaces
Change By:
Francisco Lozano
Right now, this kind of step is not supported. {CODE}public interface FooBarSteps { @Given("whatever bla bla") void givenWhateverBlaBla();}public class FooBarStepsImpl {@Overridepublic void givenWhateverBlaBla() {}}{CODE}The FooBarStepsImpl won't be detected as annotation-bearing class. However, I think it'd be great to support them. It would allow JDK Proxies for steps, and would allow separating step interface construction from actual step implementation. One example use-case would be making it possible to test, with the same stories, two "client libraries" with the same functionality but different APIs, by reimplementing the step classes using each library's API.I think the StepsFactory-related changes needed are simple (just take into account also interfaces when exploring methods for annotations), and I've identified also some changes needed in the Steps class. An ongoing, tentative and untested attempt for the required changes in the Steps class is here:https://github.com/flozano/jbehave-core/commit/1d7d002f16e7e786797b2240c535bfc0d13d97e0Any opinion about this?
Add Comment
This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c)
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
