[jbehave-dev] [jira] (JBEHAVE-1054) Regression: configuration method inherited from JUnitStories class not being overridden
Title: Message Title Mauro Talevi commented on an issue Re: Regression: configuration method inherited from JUnitStories class not being overridden Incidentally, you seem to be using both the annotated embedder and extending JUnitStories (which extends the configurable embedder). Using the two is redundant and may lead to inconsistent behaviour. It should suffice to use one of the two. Add Comment JBehave / JBEHAVE-1054 Regression: configuration method inherited from JUnitStories class not being overridden When creating a JUnitStories class, the overridden configuration method is no longer executed starting in JBehave 3.9.2. I also tested this with 3.9.3, 3.9.5 and 4.0-beta-11 and the issue persists. Only by changing the dependency version in my POM back to 3.9.1 does the method override correctly again. I have attached my StoryReporter class, the abs... 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-1054) Regression: configuration method inherited from JUnitStories class not being overridden
Title: Message Title Mauro Talevi edited a comment on an issue Re: Regression: configuration method inherited from JUnitStories class not being overridden Yes, this is a side effect of JBEHAVE-1009. The ConfigurableEmbedder now uses the configuration() method lazily only if there is no other configuration set. To override with your instance of Configuration, you can use the #useConfiguration() method in the constructor of the class inheriting from JUnitStories. The CoreStories in the core examples show how to configure using the configuration() method. If you still have problems, please provide a fully working example buildable and executable by command-line (either a zip or a git repo) so we can reproduce your behaviour. Add Comment JBehave / JBEHAVE-1054 Regression: configuration method inherited from JUnitStories class not being overridden When creating a JUnitStories class, the overridden configuration method is no longer executed starting in JBehave 3.9.2. I also tested this with 3.9.3, 3.9.5 and 4.0-beta-11 and the issue persists. Only by changing the dependency version in my POM back to 3.9.1 does the method override correctly again. I have attached my StoryReporter class, the abs... This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c
[jbehave-dev] [jira] (JBEHAVE-1053) Allow entire story to be restarted
Title: Message Title Mauro Talevi commented on an issue Re: Allow entire story to be restarted Did some cleanup on the StoryRunner implementation. Can you please verify it works on your side? Please add any different behaviour to restarting.story. Add Comment JBehave / JBEHAVE-1053 Allow entire story to be restarted For selenium tests that keep the same browser / context throughout the story, there are countless things that can go wrong such as network latency, slow application, etc. Since a false positive can cause people to quickly lose trust in the tests, others advised that the story should restart "x" amount of times before failing the test. There is a way to... 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-1054) Regression: configuration method inherited from JUnitStories class not being overridden
Title: Message Title Mauro Talevi commented on an issue Re: Regression: configuration method inherited from JUnitStories class not being overridden Yes, this is a side effect of JBEHAVE-1009 . The ConfigurableEmbedder now uses the configuration() method lazily only if there is no other configuration set. To override with your instance of Configuration, you can use the #useConfiguration() method in the constructor of the class inheriting from JUnitStories. Add Comment JBehave / JBEHAVE-1054 Regression: configuration method inherited from JUnitStories class not being overridden When creating a JUnitStories class, the overridden configuration method is no longer executed starting in JBehave 3.9.2. I also tested this with 3.9.3, 3.9.5 and 4.0-beta-11 and the issue persists. Only by changing the dependency version in my POM back to 3.9.1 does the method override correctly again. I have attached my StoryReporter class, the abs... This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c
[jbehave-scm] [scm-core/jbehave-4.x][2/4] JBEHAVE-1053: Added restarting.story to verify restarting behaviour.
commit 7f5907f34b5d11ee2f701662e888d96dbca91b74
Author: Mauro Talevi
AuthorDate: Fri, 7 Nov 2014 13:38:19 +0100
Commit: Mauro Talevi
CommitDate: Sat, 8 Nov 2014 11:07:29 +0100
JBEHAVE-1053: Added restarting.story to verify restarting behaviour.
diff --git
a/examples/core/src/main/java/org/jbehave/examples/core/CoreStories.java
b/examples/core/src/main/java/org/jbehave/examples/core/CoreStories.java
index d2adede..031f091 100755
--- a/examples/core/src/main/java/org/jbehave/examples/core/CoreStories.java
+++ b/examples/core/src/main/java/org/jbehave/examples/core/CoreStories.java
@@ -48,6 +48,7 @@ import org.jbehave.examples.core.steps.MyContext;
import org.jbehave.examples.core.steps.NamedParametersSteps;
import org.jbehave.examples.core.steps.PendingSteps;
import org.jbehave.examples.core.steps.PriorityMatchingSteps;
+import org.jbehave.examples.core.steps.RestartingSteps;
import org.jbehave.examples.core.steps.SandpitSteps;
import org.jbehave.examples.core.steps.SearchSteps;
import org.jbehave.examples.core.steps.TableSteps;
@@ -116,7 +117,8 @@ public class CoreStories extends JUnitStories {
return new InstanceStepsFactory(configuration(), new TraderSteps(new
TradingService()), new AndSteps(),
new MetaParametrisationSteps(), new CalendarSteps(), new
PriorityMatchingSteps(), new PendingSteps(),
new SandpitSteps(), new SearchSteps(), new BeforeAfterSteps(),
new CompositeSteps(),
-new NamedParametersSteps(), new
ExamplesTableParametersSteps(), new TableSteps(), new ContextSteps(context));
+new NamedParametersSteps(), new
ExamplesTableParametersSteps(), new TableSteps(),
+new ContextSteps(context), new RestartingSteps());
}
@Override
diff --git
a/examples/core/src/main/java/org/jbehave/examples/core/steps/RestartingSteps.java
b/examples/core/src/main/java/org/jbehave/examples/core/steps/RestartingSteps.java
new file mode 100644
index 000..f6c3f48
--- /dev/null
+++
b/examples/core/src/main/java/org/jbehave/examples/core/steps/RestartingSteps.java
@@ -0,0 +1,28 @@
+package org.jbehave.examples.core.steps;
+
+import org.jbehave.core.annotations.When;
+import org.jbehave.core.failures.RestartingScenarioFailure;
+import org.jbehave.core.failures.RestartingStoryFailure;
+
+public class RestartingSteps {
+ private int restartingScenario;
+ private int restartingStory;
+
+ @When("I restart scenario")
+ public void restartScenario(){
+ if ( restartingScenario < 1 ){
+ restartingScenario++;
+ throw new RestartingScenarioFailure("Restarting
scenario: "+restartingScenario);
+ }
+ }
+
+ @When("I restart story")
+ public void restartStory(){
+ if ( restartingStory < 1 ){
+ restartingStory++;
+ throw new RestartingStoryFailure("Restarting story:
"+restartingStory);
+ }
+ }
+
+}
+
diff --git
a/examples/core/src/main/java/org/jbehave/examples/core/stories/Restarting.java
b/examples/core/src/main/java/org/jbehave/examples/core/stories/Restarting.java
new file mode 100644
index 000..cc7bfa0
--- /dev/null
+++
b/examples/core/src/main/java/org/jbehave/examples/core/stories/Restarting.java
@@ -0,0 +1,15 @@
+package org.jbehave.examples.core.stories;
+
+import org.jbehave.core.steps.InjectableStepsFactory;
+import org.jbehave.core.steps.InstanceStepsFactory;
+import org.jbehave.examples.core.CoreStory;
+import org.jbehave.examples.core.steps.RestartingSteps;
+
+public class Restarting extends CoreStory {
+
+ @Override
+ public InjectableStepsFactory stepsFactory() {
+ return new InstanceStepsFactory(configuration(), new
RestartingSteps());
+ }
+
+}
diff --git
a/examples/core/src/main/java/org/jbehave/examples/core/stories/restarting.story
b/examples/core/src/main/java/org/jbehave/examples/core/stories/restarting.story
new file mode 100755
index 000..b4d5a34
--- /dev/null
+++
b/examples/core/src/main/java/org/jbehave/examples/core/stories/restarting.story
@@ -0,0 +1,8 @@
+
+Scenario: Restarting scenario
+
+When I restart scenario
+
+Scenario: Restarting story
+
+When I restart story
[jbehave-scm] [scm-core/jbehave-4.x][3/4] JBEHAVE-1053: Simplification.
commit 6b66ed9d810398451fddcb4822c22237341c877c
Author: Mauro Talevi
AuthorDate: Sat, 8 Nov 2014 11:47:02 +0100
Commit: Mauro Talevi
CommitDate: Sat, 8 Nov 2014 11:47:38 +0100
JBEHAVE-1053: Simplification.
diff --git
a/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryRunner.java
b/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryRunner.java
index 314587b..fd9af67 100755
--- a/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryRunner.java
+++ b/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryRunner.java
@@ -50,7 +50,6 @@ public class StoryRunner {
private ThreadLocal failureStrategy = new
ThreadLocal();
private ThreadLocal pendingStepStrategy = new
ThreadLocal();
private ThreadLocal storyFailure = new
ThreadLocal();
-private ThreadLocal beforeAfterStoryFailure = new
ThreadLocal();
private ThreadLocal reporter = new
ThreadLocal();
private ThreadLocal reporterStoryPath = new ThreadLocal();
private ThreadLocal storiesState = new ThreadLocal();
@@ -218,12 +217,11 @@ public class StoryRunner {
}
/**
- * Helper method to determine if the cause of a story failure contains
{@link RestartingStoryFailure}
- * @param cause - the stacktrace to check for {@link
RestartingStoryFailure}
+ * Determines if the cause of a story failure is {@link
RestartingStoryFailure}
+ * @param cause the {@link Throwable} containing the {@link
RestartingStoryFailure} in its stack trace
* @return true if found, false otherwise
*/
-public boolean hasRestartingStoryException(Throwable cause)
-{
+ private boolean restartStory(Throwable cause) {
while (cause != null) {
if (cause instanceof RestartingStoryFailure) {
return true;
@@ -248,8 +246,8 @@ public class StoryRunner {
reporter.get().afterStory(context.givenStory);
}
- // Restart entire story if determined it needs it
- if (hasRestartingStoryException(e) ||
hasRestartingStoryException(beforeAfterStoryFailure.get())) {
+ // Restart entire story if needed
+ if (restartStory(e)) {
//this is not getting logged when running in
multi-threaded mode
reporter.get().restartedStory(story, e);
restartingStory = true;
@@ -406,7 +404,6 @@ public class StoryRunner {
}
currentStrategy.set(context.configuration().failureStrategy());
storyFailure.set(null);
-beforeAfterStoryFailure.set(null);
}
private void runGivenStories(GivenStories givenStories, Map parameters, RunContext context) throws Throwable {
@@ -594,21 +591,15 @@ public class StoryRunner {
}
private final class SomethingHappened implements State {
-UUIDExceptionWrapper scenarioFailure;
+UUIDExceptionWrapper failure;
-public SomethingHappened(UUIDExceptionWrapper scenarioFailure) {
-this.scenarioFailure = scenarioFailure;
+public SomethingHappened(UUIDExceptionWrapper failure) {
+this.failure = failure;
}
public State run(Step step) {
-StepResult result = step.doNotPerform(scenarioFailure);
+StepResult result = step.doNotPerform(failure);
result.describeTo(reporter.get());
-
- if (result.getFailure() != null) {
- //persist failures to see if we need to restart
the story
-
beforeAfterStoryFailure.set(result.getFailure());
- }
-
return this;
}
}
@@ -736,7 +727,7 @@ public class StoryRunner {
public Throwable failure(State state) {
if (failed(state)) {
-return ((SomethingHappened) state).scenarioFailure.getCause();
+return ((SomethingHappened) state).failure.getCause();
}
return null;
}
[jbehave-scm] [scm-core/jbehave-4.x][4/4] JBEHAVE-1053: Support restarting scenario and story in PerformableTree.
commit 14d9c2749ef2b64c05d92591716dd191d65e2f64
Author: Mauro Talevi
AuthorDate: Sun, 9 Nov 2014 10:37:57 +0100
Commit: Mauro Talevi
CommitDate: Sun, 9 Nov 2014 10:37:57 +0100
JBEHAVE-1053: Support restarting scenario and story in PerformableTree.
diff --git
a/jbehave-core/src/main/java/org/jbehave/core/embedder/PerformableTree.java
b/jbehave-core/src/main/java/org/jbehave/core/embedder/PerformableTree.java
index a8c87f1..23e4b6f 100644
--- a/jbehave-core/src/main/java/org/jbehave/core/embedder/PerformableTree.java
+++ b/jbehave-core/src/main/java/org/jbehave/core/embedder/PerformableTree.java
@@ -17,6 +17,8 @@ import org.jbehave.core.failures.BatchFailures;
import org.jbehave.core.failures.FailingUponPendingStep;
import org.jbehave.core.failures.PendingStepFound;
import org.jbehave.core.failures.PendingStepsFound;
+import org.jbehave.core.failures.RestartingScenarioFailure;
+import org.jbehave.core.failures.RestartingStoryFailure;
import org.jbehave.core.failures.UUIDExceptionWrapper;
import org.jbehave.core.model.ExamplesTable;
import org.jbehave.core.model.GivenStories;
@@ -356,16 +358,23 @@ public class PerformableTree {
}
public void perform(RunContext context, Story story) {
+ boolean restartingStory = false;
+
try {
performCancellable(context, story);
-} catch (Throwable e) {
+if (context.restartStory()){
+ context.reporter().restartedStory(story,
context.failure(context.state()));
+ restartingStory = true;
+ perform(context, story);
+}
+} catch (InterruptedException e) {
if (context.isCancelled(story)) {
context.reporter().storyCancelled(story,
context.storyDuration(story));
context.reporter().afterStory(context.givenStory);
}
throw new UUIDExceptionWrapper(e);
} finally {
-if (!context.givenStory() && context.reporter() instanceof
ConcurrentStoryReporter) {
+if (!context.givenStory() && context.reporter() instanceof
ConcurrentStoryReporter && !restartingStory ) {
((ConcurrentStoryReporter) context.reporter()).invokeDelayed();
}
}
@@ -374,6 +383,7 @@ public class PerformableTree {
private void performCancellable(RunContext context, Story story) throws
InterruptedException {
if (context.configuration().storyControls().resetStateBeforeStory()) {
context.resetState();
+context.resetFailures();
}
context.currentPath(story.getPath());
@@ -432,6 +442,28 @@ public class PerformableTree {
resetState();
}
+ public boolean restartScenario() {
+ Throwable cause = failure(state);
+ while (cause != null) {
+ if (cause instanceof RestartingScenarioFailure) {
+ return true;
+ }
+ cause = cause.getCause();
+ }
+ return false;
+ }
+
+ public boolean restartStory() {
+ Throwable cause = failure(state);
+ while (cause != null) {
+ if (cause instanceof RestartingStoryFailure) {
+ return true;
+ }
+ cause = cause.getCause();
+ }
+ return false;
+ }
+
public void currentPath(String path) {
this.path = path;
this.reporter = configuration.storyReporter(path);
@@ -761,7 +793,8 @@ public class PerformableTree {
private boolean allowed;
private NormalPerformableScenario normalPerformableScenario;
private List examplePerformableScenarios =
new ArrayList();
-Status status;
+@SuppressWarnings("unused")
+ private Status status;
public PerformableScenario(Scenario scenario, String storyPath) {
this.scenario = scenario;
@@ -858,6 +891,18 @@ public class PerformableTree {
public Map getParameters() {
return parameters;
}
+
+ protected void performRestartableSteps(RunContext context)
+ throws InterruptedException {
+ boolean restart = true;
+ while (restart) {
+ restart = false;
+ steps.perform(context);
+ if (context.restartScenario()){
+ restart = true;
+ }
+ }
+ }
}
public static class NormalPerformableScenario extends
AbstractPerformableScenario {
@@ -880,7 +925,7 @@ public class PerformableTree {
[jbehave-scm] [scm-core][1/1] JBEHAVE-1053: Simplification.
commit ab48e7e56249713879ebb0f735536215992748b6
Author: Mauro Talevi
AuthorDate: Sat, 8 Nov 2014 11:47:02 +0100
Commit: Mauro Talevi
CommitDate: Sat, 8 Nov 2014 11:47:02 +0100
JBEHAVE-1053: Simplification.
diff --git
a/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryRunner.java
b/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryRunner.java
index 314587b..fd9af67 100755
--- a/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryRunner.java
+++ b/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryRunner.java
@@ -50,7 +50,6 @@ public class StoryRunner {
private ThreadLocal failureStrategy = new
ThreadLocal();
private ThreadLocal pendingStepStrategy = new
ThreadLocal();
private ThreadLocal storyFailure = new
ThreadLocal();
-private ThreadLocal beforeAfterStoryFailure = new
ThreadLocal();
private ThreadLocal reporter = new
ThreadLocal();
private ThreadLocal reporterStoryPath = new ThreadLocal();
private ThreadLocal storiesState = new ThreadLocal();
@@ -218,12 +217,11 @@ public class StoryRunner {
}
/**
- * Helper method to determine if the cause of a story failure contains
{@link RestartingStoryFailure}
- * @param cause - the stacktrace to check for {@link
RestartingStoryFailure}
+ * Determines if the cause of a story failure is {@link
RestartingStoryFailure}
+ * @param cause the {@link Throwable} containing the {@link
RestartingStoryFailure} in its stack trace
* @return true if found, false otherwise
*/
-public boolean hasRestartingStoryException(Throwable cause)
-{
+ private boolean restartStory(Throwable cause) {
while (cause != null) {
if (cause instanceof RestartingStoryFailure) {
return true;
@@ -248,8 +246,8 @@ public class StoryRunner {
reporter.get().afterStory(context.givenStory);
}
- // Restart entire story if determined it needs it
- if (hasRestartingStoryException(e) ||
hasRestartingStoryException(beforeAfterStoryFailure.get())) {
+ // Restart entire story if needed
+ if (restartStory(e)) {
//this is not getting logged when running in
multi-threaded mode
reporter.get().restartedStory(story, e);
restartingStory = true;
@@ -406,7 +404,6 @@ public class StoryRunner {
}
currentStrategy.set(context.configuration().failureStrategy());
storyFailure.set(null);
-beforeAfterStoryFailure.set(null);
}
private void runGivenStories(GivenStories givenStories, Map parameters, RunContext context) throws Throwable {
@@ -594,21 +591,15 @@ public class StoryRunner {
}
private final class SomethingHappened implements State {
-UUIDExceptionWrapper scenarioFailure;
+UUIDExceptionWrapper failure;
-public SomethingHappened(UUIDExceptionWrapper scenarioFailure) {
-this.scenarioFailure = scenarioFailure;
+public SomethingHappened(UUIDExceptionWrapper failure) {
+this.failure = failure;
}
public State run(Step step) {
-StepResult result = step.doNotPerform(scenarioFailure);
+StepResult result = step.doNotPerform(failure);
result.describeTo(reporter.get());
-
- if (result.getFailure() != null) {
- //persist failures to see if we need to restart
the story
-
beforeAfterStoryFailure.set(result.getFailure());
- }
-
return this;
}
}
@@ -736,7 +727,7 @@ public class StoryRunner {
public Throwable failure(State state) {
if (failed(state)) {
-return ((SomethingHappened) state).scenarioFailure.getCause();
+return ((SomethingHappened) state).failure.getCause();
}
return null;
}
Re: [jbehave-dev] problems with extending JBehave
Hi, the methods are private because they are internal and not meant to be an API. Can you explain what you're trying to do? Cheers > On 7 Nov 2014, at 11:35, Willemijn Wouters > wrote: > > Hello, > > I work on a opensource project called Unitils and at the moment we are > working on a project called unitils-jbehave. Unitils-jbehave is the glue > between Unitils & JBehave. > But we have had some difficulties because of the fact that so many things are > private. > > Is it possible to put the following things on 'protected'? > > The following methods of org.jbehave.core.steps.Steps: > o org.jbehave.core.steps.Steps.scenarioStepsHaving(ScenarioType, Stage, > Class, Outcome...) > > o org.jbehave.core.steps.Steps.createBeforeOrAfterStep(Stage, Method) > > o org.jbehave.core.steps.Steps.createBeforeOrAfterStep(Stage, Method) > > o org.jbehave.core.steps.Steps.scenarioOutcome(Method, Class Annotation>) > > o org.jbehave.core.steps.Steps.createCandidate(Method, StepType, String, > int, Configuration) > > The following methods in org.jbehave.core.steps.InstanceStepsFactory: > org.jbehave.core.steps.AbstractStepsFactory.methodReturningConverters(Class) > > The following classes/methods in org.jbehave.core.steps.StepCreator: > o all the inner classes > > o > org.unitils.jbehave.core.stepcreator.UnitilsStepCreator.StepCreatorBeforeOrAfterStep.paramConvertersWithExceptionInjector(UUIDExceptionWrapper) > > > Thanks.
[jbehave-dev] [jira] (JBEHAVE-1053) Allow entire story to be restarted
Title: Message Title Mauro Talevi updated an issue JBehave / JBEHAVE-1053 Allow entire story to be restarted Change By: Mauro Talevi Fix Version/s: 3.9.6 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-1053) Allow entire story to be restarted
Title: Message Title Mauro Talevi commented on an issue Re: Allow entire story to be restarted Pulled commit and added restarting.story in core examples. Can you please add a story that can verify the multi-threading behaviour? Add Comment JBehave / JBEHAVE-1053 Allow entire story to be restarted For selenium tests that keep the same browser / context throughout the story, there are countless things that can go wrong such as network latency, slow application, etc. Since a false positive can cause people to quickly lose trust in the tests, others advised that the story should restart "x" amount of times before failing the test. There is a way to... 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-scm] [scm-core][2/2] JBEHAVE-1053: Added restarting.story to verify restarting behaviour.
commit 42f0cf699db8d65caa0845776dd868e12585abca
Author: Mauro Talevi
AuthorDate: Fri, 7 Nov 2014 13:38:19 +0100
Commit: Mauro Talevi
CommitDate: Fri, 7 Nov 2014 13:38:19 +0100
JBEHAVE-1053: Added restarting.story to verify restarting behaviour.
diff --git
a/examples/core/src/main/java/org/jbehave/examples/core/CoreStories.java
b/examples/core/src/main/java/org/jbehave/examples/core/CoreStories.java
index 6086157..b865bb1 100755
--- a/examples/core/src/main/java/org/jbehave/examples/core/CoreStories.java
+++ b/examples/core/src/main/java/org/jbehave/examples/core/CoreStories.java
@@ -48,6 +48,7 @@ import org.jbehave.examples.core.steps.MyContext;
import org.jbehave.examples.core.steps.NamedParametersSteps;
import org.jbehave.examples.core.steps.PendingSteps;
import org.jbehave.examples.core.steps.PriorityMatchingSteps;
+import org.jbehave.examples.core.steps.RestartingSteps;
import org.jbehave.examples.core.steps.SandpitSteps;
import org.jbehave.examples.core.steps.SearchSteps;
import org.jbehave.examples.core.steps.TableSteps;
@@ -116,7 +117,8 @@ public class CoreStories extends JUnitStories {
return new InstanceStepsFactory(configuration(), new TraderSteps(new
TradingService()), new AndSteps(),
new MetaParametrisationSteps(), new CalendarSteps(), new
PriorityMatchingSteps(), new PendingSteps(),
new SandpitSteps(), new SearchSteps(), new BeforeAfterSteps(),
new CompositeSteps(),
-new NamedParametersSteps(), new
ExamplesTableParametersSteps(), new TableSteps(), new ContextSteps(context));
+new NamedParametersSteps(), new
ExamplesTableParametersSteps(), new TableSteps(),
+new ContextSteps(context), new RestartingSteps());
}
@Override
diff --git
a/examples/core/src/main/java/org/jbehave/examples/core/steps/RestartingSteps.java
b/examples/core/src/main/java/org/jbehave/examples/core/steps/RestartingSteps.java
new file mode 100644
index 000..f6c3f48
--- /dev/null
+++
b/examples/core/src/main/java/org/jbehave/examples/core/steps/RestartingSteps.java
@@ -0,0 +1,28 @@
+package org.jbehave.examples.core.steps;
+
+import org.jbehave.core.annotations.When;
+import org.jbehave.core.failures.RestartingScenarioFailure;
+import org.jbehave.core.failures.RestartingStoryFailure;
+
+public class RestartingSteps {
+ private int restartingScenario;
+ private int restartingStory;
+
+ @When("I restart scenario")
+ public void restartScenario(){
+ if ( restartingScenario < 1 ){
+ restartingScenario++;
+ throw new RestartingScenarioFailure("Restarting
scenario: "+restartingScenario);
+ }
+ }
+
+ @When("I restart story")
+ public void restartStory(){
+ if ( restartingStory < 1 ){
+ restartingStory++;
+ throw new RestartingStoryFailure("Restarting story:
"+restartingStory);
+ }
+ }
+
+}
+
diff --git
a/examples/core/src/main/java/org/jbehave/examples/core/stories/Restarting.java
b/examples/core/src/main/java/org/jbehave/examples/core/stories/Restarting.java
new file mode 100644
index 000..cc7bfa0
--- /dev/null
+++
b/examples/core/src/main/java/org/jbehave/examples/core/stories/Restarting.java
@@ -0,0 +1,15 @@
+package org.jbehave.examples.core.stories;
+
+import org.jbehave.core.steps.InjectableStepsFactory;
+import org.jbehave.core.steps.InstanceStepsFactory;
+import org.jbehave.examples.core.CoreStory;
+import org.jbehave.examples.core.steps.RestartingSteps;
+
+public class Restarting extends CoreStory {
+
+ @Override
+ public InjectableStepsFactory stepsFactory() {
+ return new InstanceStepsFactory(configuration(), new
RestartingSteps());
+ }
+
+}
diff --git
a/examples/core/src/main/java/org/jbehave/examples/core/stories/restarting.story
b/examples/core/src/main/java/org/jbehave/examples/core/stories/restarting.story
new file mode 100755
index 000..b4d5a34
--- /dev/null
+++
b/examples/core/src/main/java/org/jbehave/examples/core/stories/restarting.story
@@ -0,0 +1,8 @@
+
+Scenario: Restarting scenario
+
+When I restart scenario
+
+Scenario: Restarting story
+
+When I restart story
[jbehave-dev] [jira] (JBEHAVE-1053) Allow entire story to be restarted
Title: Message Title Mauro Talevi commented on an issue Re: Allow entire story to be restarted Thanks for the contribution! I'll have a look at it soon. As for the multi-threading reporting, it should get reported by the invokeDelayed() method in the ConcurrentReporter. Add Comment JBehave / JBEHAVE-1053 Allow entire story to be restarted For selenium tests that keep the same browser / context throughout the story, there are countless things that can go wrong such as network latency, slow application, etc. Since a false positive can cause people to quickly lose trust in the tests, others advised that the story should restart "x" amount of times before failing the test. There is a way to... 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-1051) The method StoryManager.waitUntilAllDoneOrFailed(BatchFailures) can cancel un-started stories
Title: Message Title Mauro Talevi commented on an issue Re: The method StoryManager.waitUntilAllDoneOrFailed(BatchFailures) can cancel un-started stories You mean before the loop over the RunningStory collection, and not after? You think that 100ms would make such a difference? Add Comment JBehave / JBEHAVE-1051 The method StoryManager.waitUntilAllDoneOrFailed(BatchFailures) can cancel un-started stories I run several stories in parallel using the default multi-threaded Embedder.executorService and configure it with EmbedderControls.threads > 1 Sometimes the JBEHAVE ends and no scenario (but before- and after- scenario) of my stories was even started. It is not repeatable, sometims it goes good. I founded out, that the method StoryManager.waitUntilAllDo... 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-1052) Upgrade Selenium version
Title: Message Title Mauro Talevi commented on an issue Re: Upgrade Selenium version Please note you can always upgrade the selenium version via the Maven section. Add Comment JBehave / JBEHAVE-1052 Upgrade Selenium version I am using Jbehave web 3.5.5 with Selenium 3.26.0 which in turn support till Mozilla v16. Could you please upgrade Jbehave web to support latest selenium webdriver and Mozilla versions. 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-1052) Upgrade Selenium version
Title: Message Title Mauro Talevi updated an issue JBehave / JBEHAVE-1052 Upgrade Selenium version Change By: Mauro Talevi Affects Version/s: web-3.5.5 Fix Version/s: web-3.6 Summary: Jbehave supports for new Mozilla Upgrade Selenium version 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
Re: [jbehave-dev] Generics doesn't work for StringListConverter, List is not recognized as a ParameterType
Versions 3.9.5 and 4.0-beta-11 are released and synched to Maven Central.
On 02/10/2014 08:16, Matthieu Mestrez wrote:
Nice ! You fixed it that fast !
Thanks for that.
Do you know when i can expect a release ?
2014-10-01 10:15 GMT+02:00 Matthieu Mestrez
mailto:mestrez.matth...@gmail.com>>:
Thanks for the follow-up
I've created a Jira issue here :
https://jira.codehaus.org/browse/JBEHAVE-1049
2014-10-01 1:02 GMT+02:00 Mauro Talevi mailto:mauro.tal...@aquilonia.org>>:
Yes, there is a problem but not in the converter. Rather,
the StepCreator tries to use the parameter types instead of
the generic parameter types.
Could you please raise a Jira issue for this?
Cheers
On 30/09/2014 15:19, Matthieu Mestrez wrote:
Since i'm behind a proxy at work i can only give you a zip
file to work with by this way :
http://www.filedropper.com/meta-string-list
2014-09-30 15:52 GMT+02:00 Matthieu Mestrez
mailto:mestrez.matth...@gmail.com>>:
Since i'm behind a proxy at work i can only give you a
zip file to work with by this way :
http://www.filedropper.com/meta-string-list
Or attached here, not sure it will work through a mailing
list though :
2014-09-30 15:00 GMT+02:00 Mauro Talevi
mailto:mauro.tal...@aquilonia.org>>:
Could you provide a sample project that reproduces
the desired behaviour?
> On 30 Sep 2014, at 13:01, Matthieu Mestrez
mailto:mestrez.matth...@gmail.com>> wrote:
>
> Hello,
>
> I've been trying to make use of a list of strings
in a Meta in this context :
>
> Scenario: 1. First Case
> Meta :
> @Dataset firstDataset.xml, secondDataset.xml
> Given ...
> When ..
> Then ...
>
> And in the
> @BeforeScenario
> public void initializeDataset(@Named("Dataset")
List dbUnitFiles) {
> ...
> }
>
>
> The scenario fails because
"org.jbehave.core.steps.ParameterConverters$ParameterConvertionFailed:
No parameter converter for interface java.util.List'
>
>
> If i debug, he passes through the
StringListConverter, but in the accept method the
type is not an instance of ParameterizedType, because
in the StepCreator class you use
method.getParameterTypes() that doesn't retrieve de
generics but the Class type (so java.util.List)
>
> I think that you should use for that Parameter
class the Type and not the Class
>
>
> Or maybe i've made a mistake somewhere
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Mestrez Matthieu
avenue Jolé 11
1160 Auderghem
GSM : 0494/77.26.87
e-mail : mestrez.matth...@gmail.com
<mailto:mestrez.matth...@gmail.com>
--
Mestrez Matthieu
avenue Jolé 11
1160 Auderghem
GSM : 0494/77.26.87
e-mail : mestrez.matth...@gmail.com
<mailto:mestrez.matth...@gmail.com>
--
Mestrez Matthieu
avenue Jolé 11
1160 Auderghem
GSM : 0494/77.26.87
e-mail : mestrez.matth...@gmail.com
<mailto:mestrez.matth...@gmail.com>
--
Mestrez Matthieu
avenue Jolé 11
1160 Auderghem
GSM : 0494/77.26.87
e-mail : mestrez.matth...@gmail.com <mailto:mestrez.matth...@gmail.com>
[jbehave-scm] [scm-core/jbehave-4.0-beta-11][1/1] [maven-release-plugin] copy for tag jbehave-4.0-beta-11
Tag: jbehave-4.0-beta-11 (added) Type: annotated Commit: c7052ae46c2477fe8ef8023c0f5334ca4a693051 Tagger: tag_info[:taggername] tag_info[:taggeremail] Message: [maven-release-plugin] copy for tag jbehave-4.0-beta-11
[jbehave-scm] [scm-core/jbehave-3.9.5][1/1] [maven-release-plugin] copy for tag jbehave-3.9.5
Tag: jbehave-3.9.5 (added) Type: annotated Commit: e4c51bb078d44fd7e4338a5137df9e070a47dc46 Tagger: tag_info[:taggername] tag_info[:taggeremail] Message: [maven-release-plugin] copy for tag jbehave-3.9.5
[jbehave-scm] [scm-core/jbehave-4.x][1/1] Updated release notes.
commit bace2c3017582f989dcd09d185f4c845d831180b Author: Mauro Talevi AuthorDate: Sun, 5 Oct 2014 11:58:40 +0200 Commit: Mauro Talevi CommitDate: Sun, 5 Oct 2014 11:59:18 +0200 Updated release notes. diff --git a/distribution/src/site/content/release-notes.html b/distribution/src/site/content/release-notes.html index c38985c..f9727cc 100755 --- a/distribution/src/site/content/release-notes.html +++ b/distribution/src/site/content/release-notes.html @@ -5,6 +5,29 @@ +JBehave Core - Version 3.9.5 (Oct 4, 2014) + +Bug + + +[JBEHAVE-1046] - FailingUponPendingSteps strategy not honoured + +[JBEHAVE-1049] - StepCreator doesn't support method generics parameters + +[JBEHAVE-1050] - Last of two subsequent AND-clauses with translated keywords is not performed + +[JBEHAVE-1051] - The method StoryManager.waitUntilAllDoneOrFailed(BatchFailures) can cancel un-started stories + + + +Improvement + + +[JBEHAVE-1045] - Support for class-based AOP in step classes in Spring + +[JBEHAVE-1048] - Update toString() to show the system based values + + JBehave Core - Version 3.9.4 (Aug 24, 2014)
[jbehave-scm] [scm-core][1/1] Updated release notes.
commit 7b32d921b3c4eeae188fa7d3fab980b9476adf3e Author: Mauro Talevi AuthorDate: Sun, 5 Oct 2014 11:58:40 +0200 Commit: Mauro Talevi CommitDate: Sun, 5 Oct 2014 11:58:40 +0200 Updated release notes. diff --git a/distribution/src/site/content/release-notes.html b/distribution/src/site/content/release-notes.html index c38985c..f9727cc 100755 --- a/distribution/src/site/content/release-notes.html +++ b/distribution/src/site/content/release-notes.html @@ -5,6 +5,29 @@ +JBehave Core - Version 3.9.5 (Oct 4, 2014) + +Bug + + +[JBEHAVE-1046] - FailingUponPendingSteps strategy not honoured + +[JBEHAVE-1049] - StepCreator doesn't support method generics parameters + +[JBEHAVE-1050] - Last of two subsequent AND-clauses with translated keywords is not performed + +[JBEHAVE-1051] - The method StoryManager.waitUntilAllDoneOrFailed(BatchFailures) can cancel un-started stories + + + +Improvement + + +[JBEHAVE-1045] - Support for class-based AOP in step classes in Spring + +[JBEHAVE-1048] - Update toString() to show the system based values + + JBehave Core - Version 3.9.4 (Aug 24, 2014)
[jbehave-dev] [jira] (JBEHAVE-1050) Last of two subsequent AND-clauses with translated keywords is not performed
Title: Message Title Mauro Talevi resolved an issue as Not A Bug You had two misconfigurations: 1. The i18n/keywords_ru.properties was not in the Maven classpath, masked by the (unnecessary) override of the resources 2. The StepCollector also needs to know about the keywords used. Please refer to the attached patch for a working version. PS: Note that JBehave is not yet tested with JDK 1.8. It should work but I've tested with 1.7. JBehave / JBEHAVE-1050 Last of two subsequent AND-clauses with translated keywords is not performed Change By: Mauro Talevi Resolution: Not A Bug Fix Version/s: 3.9.5 Assignee: Mauro Talevi Status: Open Resolved Add Comment This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7a
[jbehave-dev] [jira] (JBEHAVE-1050) Last of two subsequent AND-clauses with translated keywords is not performed
Title: Message Title Mauro Talevi updated an issue JBehave / JBEHAVE-1050 Last of two subsequent AND-clauses with translated keywords is not performed Patch with configuration changes to get the step matching working with custom locale. Change By: Mauro Talevi Attachment: JBEHAVE-1050.patch 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-1046) FailingUponPendingSteps strategy not honoured
Title: Message Title Mauro Talevi resolved an issue as Fixed Added examples/core/src/main/java/org/jbehave/examples/core/CoreStoriesFailingUponPending.java to verify behaviour. JBehave / JBEHAVE-1046 FailingUponPendingSteps strategy not honoured Change By: Mauro Talevi Resolution: Fixed Assignee: Mauro Talevi Status: Open Resolved 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-scm] [scm-core/jbehave-4.x][1/1] JBEHAVE-1046: Added stories configuration to verify failing behaviour upon pending steps.
commit 0de5aa2ec14cf17b225b39e4a575a677c100cb44
Author: Mauro Talevi
AuthorDate: Sun, 5 Oct 2014 00:06:56 +0200
Commit: Mauro Talevi
CommitDate: Sun, 5 Oct 2014 00:07:53 +0200
JBEHAVE-1046: Added stories configuration to verify failing behaviour upon
pending steps.
diff --git
a/examples/core/src/main/java/org/jbehave/examples/core/CoreStoriesFailingUponPending.java
b/examples/core/src/main/java/org/jbehave/examples/core/CoreStoriesFailingUponPending.java
new file mode 100644
index 000..b31737c
--- /dev/null
+++
b/examples/core/src/main/java/org/jbehave/examples/core/CoreStoriesFailingUponPending.java
@@ -0,0 +1,26 @@
+package org.jbehave.examples.core;
+
+import static org.jbehave.core.io.CodeLocations.codeLocationFromClass;
+
+import java.util.List;
+
+import org.jbehave.core.configuration.Configuration;
+import org.jbehave.core.failures.FailingUponPendingStep;
+import org.jbehave.core.io.StoryFinder;
+
+/**
+ */
+public class CoreStoriesFailingUponPending extends CoreStories {
+
+ public Configuration configuration() {
+ return super.configuration()
+ .usePendingStepStrategy(new
FailingUponPendingStep());
+ }
+
+@Override
+protected List storyPaths() {
+String filter = System.getProperty("story.filter", "**/pending.story");
+return new
StoryFinder().findPaths(codeLocationFromClass(this.getClass()), filter, "");
+}
+
+}
\ No newline at end of file
[jbehave-scm] [scm-core][1/1] JBEHAVE-1046: Added stories configuration to verify failing behaviour upon pending steps.
commit 3a84a8f8a59973ccf70796278a7ff1d6d2504069
Author: Mauro Talevi
AuthorDate: Sun, 5 Oct 2014 00:06:56 +0200
Commit: Mauro Talevi
CommitDate: Sun, 5 Oct 2014 00:06:56 +0200
JBEHAVE-1046: Added stories configuration to verify failing behaviour upon
pending steps.
diff --git
a/examples/core/src/main/java/org/jbehave/examples/core/CoreStoriesFailingUponPending.java
b/examples/core/src/main/java/org/jbehave/examples/core/CoreStoriesFailingUponPending.java
new file mode 100644
index 000..b31737c
--- /dev/null
+++
b/examples/core/src/main/java/org/jbehave/examples/core/CoreStoriesFailingUponPending.java
@@ -0,0 +1,26 @@
+package org.jbehave.examples.core;
+
+import static org.jbehave.core.io.CodeLocations.codeLocationFromClass;
+
+import java.util.List;
+
+import org.jbehave.core.configuration.Configuration;
+import org.jbehave.core.failures.FailingUponPendingStep;
+import org.jbehave.core.io.StoryFinder;
+
+/**
+ */
+public class CoreStoriesFailingUponPending extends CoreStories {
+
+ public Configuration configuration() {
+ return super.configuration()
+ .usePendingStepStrategy(new
FailingUponPendingStep());
+ }
+
+@Override
+protected List storyPaths() {
+String filter = System.getProperty("story.filter", "**/pending.story");
+return new
StoryFinder().findPaths(codeLocationFromClass(this.getClass()), filter, "");
+}
+
+}
\ No newline at end of file
[jbehave-dev] [jira] (JBEHAVE-1051) The method StoryManager.waitUntilAllDoneOrFailed(BatchFailures) can cancel un-started stories
Title: Message Title Mauro Talevi resolved an issue as Duplicate Duplicate of JBEHAVE-1046. JBehave / JBEHAVE-1051 The method StoryManager.waitUntilAllDoneOrFailed(BatchFailures) can cancel un-started stories Change By: Mauro Talevi Resolution: Duplicate Fix Version/s: 3.9.5 Status: Open Resolved 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-scm] [scm-core/jbehave-4.x][1/1] JBEHAVE-1046: Wait for running stories to start, if any are present.
commit 052d3379cab442789e2f9f60cdf44a766a18c969
Author: Mauro Talevi
AuthorDate: Sat, 4 Oct 2014 19:18:20 +0100
Commit: Mauro Talevi
CommitDate: Sat, 4 Oct 2014 23:27:07 +0200
JBEHAVE-1046: Wait for running stories to start, if any are present.
Conflicts:
jbehave-core/src/main/java/org/jbehave/core/embedder/StoryManager.java
diff --git
a/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryManager.java
b/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryManager.java
index dcf4f6e..da944c6 100644
--- a/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryManager.java
+++ b/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryManager.java
@@ -157,11 +157,16 @@ public class StoryManager {
}
public void waitUntilAllDoneOrFailed(RunContext context) {
+if ( runningStories.values().isEmpty() ) {
+ return;
+}
boolean allDone = false;
-while (!allDone) {
+boolean started = false;
+while (!allDone || !started) {
allDone = true;
for (RunningStory runningStory : runningStories.values()) {
if ( runningStory.isStarted() ){
+ started = true;
Story story = runningStory.getStory();
Future future =
runningStory.getFuture();
if (!future.isDone()) {
@@ -195,6 +200,8 @@ public class StoryManager {
}
}
}
+} else {
+ started = false;
}
}
tickTock();
[jbehave-scm] [scm-core][1/1] JBEHAVE-1046: Wait for running stories to start, if any are present.
commit f9f27c82a41c0483b29f3d2b7bafaff7d7cb8042
Author: Mauro Talevi
AuthorDate: Sat, 4 Oct 2014 19:18:20 +0100
Commit: Mauro Talevi
CommitDate: Sat, 4 Oct 2014 19:18:20 +0100
JBEHAVE-1046: Wait for running stories to start, if any are present.
diff --git
a/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryManager.java
b/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryManager.java
index 2414cf7..123084a 100644
--- a/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryManager.java
+++ b/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryManager.java
@@ -139,11 +139,16 @@ public class StoryManager {
}
public void waitUntilAllDoneOrFailed(BatchFailures failures) {
+if ( runningStories.values().isEmpty() ) {
+ return;
+}
boolean allDone = false;
-while (!allDone) {
+boolean started = false;
+while (!allDone || !started) {
allDone = true;
for (RunningStory runningStory : runningStories.values()) {
if ( runningStory.isStarted() ){
+ started = true;
Story story = runningStory.getStory();
Future future =
runningStory.getFuture();
if (!future.isDone()) {
@@ -177,6 +182,8 @@ public class StoryManager {
}
}
}
+} else {
+ started = false;
}
}
tickTock();
Re: [jbehave-dev] Generics doesn't work for StringListConverter, List is not recognized as a ParameterType
Thank you for reporting the issue and providing the suggested fix.
We'll push out a release on the weekend.
On 02/10/2014 07:16, Matthieu Mestrez wrote:
Nice ! You fixed it that fast !
Thanks for that.
Do you know when i can expect a release ?
2014-10-01 10:15 GMT+02:00 Matthieu Mestrez
mailto:mestrez.matth...@gmail.com>>:
Thanks for the follow-up
I've created a Jira issue here :
https://jira.codehaus.org/browse/JBEHAVE-1049
2014-10-01 1:02 GMT+02:00 Mauro Talevi mailto:mauro.tal...@aquilonia.org>>:
Yes, there is a problem but not in the converter. Rather,
the StepCreator tries to use the parameter types instead of
the generic parameter types.
Could you please raise a Jira issue for this?
Cheers
On 30/09/2014 15:19, Matthieu Mestrez wrote:
Since i'm behind a proxy at work i can only give you a zip
file to work with by this way :
http://www.filedropper.com/meta-string-list
2014-09-30 15:52 GMT+02:00 Matthieu Mestrez
mailto:mestrez.matth...@gmail.com>>:
Since i'm behind a proxy at work i can only give you a
zip file to work with by this way :
http://www.filedropper.com/meta-string-list
Or attached here, not sure it will work through a mailing
list though :
2014-09-30 15:00 GMT+02:00 Mauro Talevi
mailto:mauro.tal...@aquilonia.org>>:
Could you provide a sample project that reproduces
the desired behaviour?
> On 30 Sep 2014, at 13:01, Matthieu Mestrez
mailto:mestrez.matth...@gmail.com>> wrote:
>
> Hello,
>
> I've been trying to make use of a list of strings
in a Meta in this context :
>
> Scenario: 1. First Case
> Meta :
> @Dataset firstDataset.xml, secondDataset.xml
> Given ...
> When ..
> Then ...
>
> And in the
> @BeforeScenario
> public void initializeDataset(@Named("Dataset")
List dbUnitFiles) {
> ...
> }
>
>
> The scenario fails because
"org.jbehave.core.steps.ParameterConverters$ParameterConvertionFailed:
No parameter converter for interface java.util.List'
>
>
> If i debug, he passes through the
StringListConverter, but in the accept method the
type is not an instance of ParameterizedType, because
in the StepCreator class you use
method.getParameterTypes() that doesn't retrieve de
generics but the Class type (so java.util.List)
>
> I think that you should use for that Parameter
class the Type and not the Class
>
>
> Or maybe i've made a mistake somewhere
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Mestrez Matthieu
avenue Jolé 11
1160 Auderghem
GSM : 0494/77.26.87
e-mail : mestrez.matth...@gmail.com
<mailto:mestrez.matth...@gmail.com>
--
Mestrez Matthieu
avenue Jolé 11
1160 Auderghem
GSM : 0494/77.26.87
e-mail : mestrez.matth...@gmail.com
<mailto:mestrez.matth...@gmail.com>
--
Mestrez Matthieu
avenue Jolé 11
1160 Auderghem
GSM : 0494/77.26.87
e-mail : mestrez.matth...@gmail.com
<mailto:mestrez.matth...@gmail.com>
--
Mestrez Matthieu
avenue Jolé 11
1160 Auderghem
GSM : 0494/77.26.87
e-mail : mestrez.matth...@gmail.com <mailto:mestrez.matth...@gmail.com>
[jbehave-scm] [scm-core/jbehave-4.x][1/1] JBEHAVE-1049: Support generic parameter types in StepCreator.
commit ba6ad54984c91ff7ab1b53a862c60d6233f6078e
Author: Mauro Talevi
AuthorDate: Wed, 1 Oct 2014 21:10:53 +0100
Commit: Mauro Talevi
CommitDate: Wed, 1 Oct 2014 21:15:12 +0100
JBEHAVE-1049: Support generic parameter types in StepCreator.
diff --git a/jbehave-core/src/main/java/org/jbehave/core/steps/StepCreator.java
b/jbehave-core/src/main/java/org/jbehave/core/steps/StepCreator.java
index ba6aa89..db76ef7 100755
--- a/jbehave-core/src/main/java/org/jbehave/core/steps/StepCreator.java
+++ b/jbehave-core/src/main/java/org/jbehave/core/steps/StepCreator.java
@@ -787,14 +787,14 @@ public class StepCreator {
private final ParameterConverters parameterConverters;
private final Paranamer paranamer;
private final Meta meta;
-private int methodArity;
+private final Type[] parameterTypes;
public MethodInvoker(Method method, ParameterConverters
parameterConverters, Paranamer paranamer, Meta meta) {
this.method = method;
this.parameterConverters = parameterConverters;
this.paranamer = paranamer;
this.meta = meta;
-this.methodArity = method.getParameterTypes().length;
+this.parameterTypes = method.getGenericParameterTypes();
}
public void invoke() throws InvocationTargetException,
IllegalAccessException {
@@ -802,36 +802,35 @@ public class StepCreator {
}
private Parameter[] methodParameters() {
-Parameter[] parameters = new Parameter[methodArity];
-String[] annotationNamedParameters =
annotatedParameterNames(method);
-String[] parameterNames = paranamer.lookupParameterNames(method,
false);
-Class[] parameterTypes = method.getParameterTypes();
+Parameter[] parameters = new Parameter[parameterTypes.length];
+String[] annotatedNames = annotatedParameterNames(method);
+String[] paranamerNames = paranamer.lookupParameterNames(method,
false);
-for (int paramPosition = 0; paramPosition < methodArity;
paramPosition++) {
-String paramName = parameterNameFor(paramPosition,
annotationNamedParameters, parameterNames);
-parameters[paramPosition] = new Parameter(paramPosition,
parameterTypes[paramPosition], paramName);
+for (int position = 0; position < parameterTypes.length;
position++) {
+String name = parameterNameFor(position, annotatedNames,
paranamerNames);
+parameters[position] = new Parameter(position,
parameterTypes[position], name);
}
return parameters;
}
-private String parameterNameFor(int paramPosition, String[]
annotationNamedParameters, String[] parameterNames) {
-String nameFromAnnotation =
nameIfValidPositionInArray(annotationNamedParameters, paramPosition);
-String parameterName = nameIfValidPositionInArray(parameterNames,
paramPosition);
-if (nameFromAnnotation != null) {
-return nameFromAnnotation;
-} else if (parameterName != null) {
-return parameterName;
+private String parameterNameFor(int position, String[] annotatedNames,
String[] paranamerNames) {
+String annotatedName = nameByPosition(annotatedNames, position);
+String paranamerName = nameByPosition(paranamerNames, position);
+if (annotatedName != null) {
+return annotatedName;
+} else if (paranamerName != null) {
+return paranamerName;
}
return null;
}
-private String nameIfValidPositionInArray(String[] paramNames, int
paramPosition) {
-return paramPosition < paramNames.length ?
paramNames[paramPosition] : null;
+private String nameByPosition(String[] names, int position) {
+return position < names.length ? names[position] : null;
}
private Object[] parameterValuesFrom(Meta meta) {
-Object[] values = new Object[methodArity];
+Object[] values = new Object[parameterTypes.length];
for (Parameter parameter : methodParameters()) {
values[parameter.position] =
parameterConverters.convert(parameter.valueFrom(meta), parameter.type);
}
@@ -840,10 +839,10 @@ public class StepCreator {
private class Parameter {
private final int position;
-private final Class type;
+private final Type type;
private final String name;
-public Parameter(int position, Class type, String name) {
+public Parameter(int position, Type type, String name) {
this.position = position;
this.type = type;
this.name = name;
[jbehave-dev] [jira] (JBEHAVE-1049) StepCreator doesn't support method generics parameters
Title: Message Title Mauro Talevi resolved an issue as Fixed JBehave / JBEHAVE-1049 StepCreator doesn't support method generics parameters Change By: Mauro Talevi Resolution: Fixed Assignee: Mauro Talevi Status: Open Resolved 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-scm] [scm-core][1/1] JBEHAVE-1049: Support generic parameter types in StepCreator.
commit e8030b13b05183d1fcb12e1f6a910c10b0e5c2cd
Author: Mauro Talevi
AuthorDate: Wed, 1 Oct 2014 21:10:53 +0100
Commit: Mauro Talevi
CommitDate: Wed, 1 Oct 2014 21:10:53 +0100
JBEHAVE-1049: Support generic parameter types in StepCreator.
diff --git a/jbehave-core/src/main/java/org/jbehave/core/steps/StepCreator.java
b/jbehave-core/src/main/java/org/jbehave/core/steps/StepCreator.java
index bb1171a..f61138d 100755
--- a/jbehave-core/src/main/java/org/jbehave/core/steps/StepCreator.java
+++ b/jbehave-core/src/main/java/org/jbehave/core/steps/StepCreator.java
@@ -784,14 +784,14 @@ public class StepCreator {
private final ParameterConverters parameterConverters;
private final Paranamer paranamer;
private final Meta meta;
-private int methodArity;
+private final Type[] parameterTypes;
public MethodInvoker(Method method, ParameterConverters
parameterConverters, Paranamer paranamer, Meta meta) {
this.method = method;
this.parameterConverters = parameterConverters;
this.paranamer = paranamer;
this.meta = meta;
-this.methodArity = method.getParameterTypes().length;
+this.parameterTypes = method.getGenericParameterTypes();
}
public void invoke() throws InvocationTargetException,
IllegalAccessException {
@@ -799,36 +799,35 @@ public class StepCreator {
}
private Parameter[] methodParameters() {
-Parameter[] parameters = new Parameter[methodArity];
-String[] annotationNamedParameters =
annotatedParameterNames(method);
-String[] parameterNames = paranamer.lookupParameterNames(method,
false);
-Class[] parameterTypes = method.getParameterTypes();
+Parameter[] parameters = new Parameter[parameterTypes.length];
+String[] annotatedNames = annotatedParameterNames(method);
+String[] paranamerNames = paranamer.lookupParameterNames(method,
false);
-for (int paramPosition = 0; paramPosition < methodArity;
paramPosition++) {
-String paramName = parameterNameFor(paramPosition,
annotationNamedParameters, parameterNames);
-parameters[paramPosition] = new Parameter(paramPosition,
parameterTypes[paramPosition], paramName);
+for (int position = 0; position < parameterTypes.length;
position++) {
+String name = parameterNameFor(position, annotatedNames,
paranamerNames);
+parameters[position] = new Parameter(position,
parameterTypes[position], name);
}
return parameters;
}
-private String parameterNameFor(int paramPosition, String[]
annotationNamedParameters, String[] parameterNames) {
-String nameFromAnnotation =
nameIfValidPositionInArray(annotationNamedParameters, paramPosition);
-String parameterName = nameIfValidPositionInArray(parameterNames,
paramPosition);
-if (nameFromAnnotation != null) {
-return nameFromAnnotation;
-} else if (parameterName != null) {
-return parameterName;
+private String parameterNameFor(int position, String[] annotatedNames,
String[] paranamerNames) {
+String annotatedName = nameByPosition(annotatedNames, position);
+String paranamerName = nameByPosition(paranamerNames, position);
+if (annotatedName != null) {
+return annotatedName;
+} else if (paranamerName != null) {
+return paranamerName;
}
return null;
}
-private String nameIfValidPositionInArray(String[] paramNames, int
paramPosition) {
-return paramPosition < paramNames.length ?
paramNames[paramPosition] : null;
+private String nameByPosition(String[] names, int position) {
+return position < names.length ? names[position] : null;
}
private Object[] parameterValuesFrom(Meta meta) {
-Object[] values = new Object[methodArity];
+Object[] values = new Object[parameterTypes.length];
for (Parameter parameter : methodParameters()) {
values[parameter.position] =
parameterConverters.convert(parameter.valueFrom(meta), parameter.type);
}
@@ -837,10 +836,10 @@ public class StepCreator {
private class Parameter {
private final int position;
-private final Class type;
+private final Type type;
private final String name;
-public Parameter(int position, Class type, String name) {
+public Parameter(int position, Type type, String name) {
this.position = position;
this.type = type;
this.name = name;
[jbehave-dev] [jira] (JBEHAVE-1049) StepCreator doesn't support method generics parameters
Title: Message Title Mauro Talevi updated an issue JBehave / JBEHAVE-1049 StepCreator doesn't support method generics parameters Change By: Mauro Talevi Summary: StepCreator doesn't take Type support method generics parameters but Class of parameters 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-1049) StepCreator doesn't take Type parameters but Class of parameters
Title: Message Title Mauro Talevi updated an issue JBehave / JBEHAVE-1049 StepCreator doesn't take Type parameters but Class of parameters Change By: Mauro Talevi Affects Version/s: 3.9.5 Affects Version/s: 3.9.4 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
Re: [jbehave-dev] Generics doesn't work for StringListConverter, List is not recognized as a ParameterType
Yes, there is a problem but not in the converter. Rather, the
StepCreator tries to use the parameter types instead of the generic
parameter types.
Could you please raise a Jira issue for this?
Cheers
On 30/09/2014 15:19, Matthieu Mestrez wrote:
Since i'm behind a proxy at work i can only give you a zip file to
work with by this way :
http://www.filedropper.com/meta-string-list
2014-09-30 15:52 GMT+02:00 Matthieu Mestrez
mailto:mestrez.matth...@gmail.com>>:
Since i'm behind a proxy at work i can only give you a zip file to
work with by this way :
http://www.filedropper.com/meta-string-list
Or attached here, not sure it will work through a mailing list
though :
2014-09-30 15:00 GMT+02:00 Mauro Talevi
mailto:mauro.tal...@aquilonia.org>>:
Could you provide a sample project that reproduces the desired
behaviour?
> On 30 Sep 2014, at 13:01, Matthieu Mestrez
mailto:mestrez.matth...@gmail.com>> wrote:
>
> Hello,
>
> I've been trying to make use of a list of strings in a Meta
in this context :
>
> Scenario: 1. First Case
> Meta :
> @Dataset firstDataset.xml, secondDataset.xml
> Given ...
> When ..
> Then ...
>
> And in the
> @BeforeScenario
> public void initializeDataset(@Named("Dataset") List
dbUnitFiles) {
> ...
> }
>
>
> The scenario fails because
"org.jbehave.core.steps.ParameterConverters$ParameterConvertionFailed:
No parameter converter for interface java.util.List'
>
>
> If i debug, he passes through the StringListConverter, but
in the accept method the type is not an instance of
ParameterizedType, because in the StepCreator class you use
method.getParameterTypes() that doesn't retrieve de generics
but the Class type (so java.util.List)
>
> I think that you should use for that Parameter class the
Type and not the Class
>
>
> Or maybe i've made a mistake somewhere
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Mestrez Matthieu
avenue Jolé 11
1160 Auderghem
GSM : 0494/77.26.87
e-mail : mestrez.matth...@gmail.com
<mailto:mestrez.matth...@gmail.com>
--
Mestrez Matthieu
avenue Jolé 11
1160 Auderghem
GSM : 0494/77.26.87
e-mail : mestrez.matth...@gmail.com <mailto:mestrez.matth...@gmail.com>
Re: [jbehave-dev] Generics doesn't work for StringListConverter, List is not recognized as a ParameterType
Could you provide a sample project that reproduces the desired behaviour?
> On 30 Sep 2014, at 13:01, Matthieu Mestrez wrote:
>
> Hello,
>
> I've been trying to make use of a list of strings in a Meta in this context :
>
> Scenario: 1. First Case
> Meta :
> @Dataset firstDataset.xml, secondDataset.xml
> Given ...
> When ..
> Then ...
>
> And in the
> @BeforeScenario
> public void initializeDataset(@Named("Dataset") List dbUnitFiles) {
> ...
> }
>
>
> The scenario fails because
> "org.jbehave.core.steps.ParameterConverters$ParameterConvertionFailed: No
> parameter converter for interface java.util.List'
>
>
> If i debug, he passes through the StringListConverter, but in the accept
> method the type is not an instance of ParameterizedType, because in the
> StepCreator class you use method.getParameterTypes() that doesn't retrieve de
> generics but the Class type (so java.util.List)
>
> I think that you should use for that Parameter class the Type and not the
> Class
>
>
> Or maybe i've made a mistake somewhere
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [jbehave-dev] Generics doesn't work for StringListConverter, List is not recognized as a ParameterType
ParameterConverter#accept(Type) method supports generics.
Which version of JBehave are you on?
> On 30 Sep 2014, at 13:01, Matthieu Mestrez wrote:
>
> Hello,
>
> I've been trying to make use of a list of strings in a Meta in this context :
>
> Scenario: 1. First Case
> Meta :
> @Dataset firstDataset.xml, secondDataset.xml
> Given ...
> When ..
> Then ...
>
> And in the
> @BeforeScenario
> public void initializeDataset(@Named("Dataset") List dbUnitFiles) {
> ...
> }
>
>
> The scenario fails because
> "org.jbehave.core.steps.ParameterConverters$ParameterConvertionFailed: No
> parameter converter for interface java.util.List'
>
>
> If i debug, he passes through the StringListConverter, but in the accept
> method the type is not an instance of ParameterizedType, because in the
> StepCreator class you use method.getParameterTypes() that doesn't retrieve de
> generics but the Class type (so java.util.List)
>
> I think that you should use for that Parameter class the Type and not the
> Class
>
>
> Or maybe i've made a mistake somewhere
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] (JBEHAVE-1048) Update toString() to show the system based values
Title: Message Title Mauro Talevi resolved an issue as Fixed Pulled with thanks JBehave / JBEHAVE-1048 Update toString() to show the system based values Change By: Mauro Talevi Resolution: Fixed Status: Open Resolved 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-1048) Update toString() to show the system based values
Title: Message Title Mauro Talevi updated an issue JBehave / JBEHAVE-1048 Update toString() to show the system based values Change By: Mauro Talevi Fix Version/s: 4.x Fix Version/s: 3.9.5 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-790) When using PerScenarioWebDriverSteps.java and GivenStories then occurs DelegateWebDriverNotFound exception
Title: Message Title Mauro Talevi commented on an issue Re: When using PerScenarioWebDriverSteps.java and GivenStories then occurs DelegateWebDriverNotFound exception The Before/AfterStories are treated as a "story" in itself, so as to allow the other stories to run in multi-threaded mode. What do you mean by "running all the conditions in the same thread"? Add Comment JBehave / JBEHAVE-790 When using PerScenarioWebDriverSteps.java and GivenStories then occurs DelegateWebDriverNotFound exception When I use as life cycle steps PerScenarioWebDriverSteps and try to execute scenario which has GivenStories section then occurs DelegateWebDriverNotFound. What happens during executions: 1. Firefox blank window is opened (for top level scenario?) 2. Another firefox windows is opened and executes scenario from GivenStories section then this window is ... 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
Re: [jbehave-dev] Step Class Instance Reuse?
The simplest and most important of reasons is that JBehave and other BDD frameworks are not unit-testing frameworks. They are used for integration testing which by its nature is fundamentally different from unit testing. For one thing, it spans multiple methods and classes, while each unit test corresponds to a single method. On 07/09/2014 22:28, Chad Wilson wrote: I was quite confused by how jbehave and other bdd frameworks handle instantiation. Having familiarity with unit testing frameworks, I came in with the expectation that steps classes would be handled like classes in JUnit, one instance per method with instantiation handled by the framework. Is there a particular reason for deviating from this pattern other than the complexity it would require for the framework to do instantiation? Chad On 9/7/2014 12:20 PM, Mauro Talevi wrote: The steps classes are instantiated only once per run context, i.e. for the set of stories. The same steps classes are reused for all scenarios. A context object is the recommended way to hold state in a scenario, and you'd use a thread local if you are in multi-threading mode. If you need to reset the state before or after each scenario, you can do so via the @BeforeScenario and @AfterScenario annotations, or using the Lifecycle steps in your story. If you have a specific use case in mind, feel free to share it. On 07/09/2014 15:26, Anders wrote: Message Title No, no problem seen, and thanks for the quick reply. The reason I ask is just to know if the state of the steps class instance is guaranteed to be available during the whole scenario. We normally use a thread local singleton context manager to hold the state of the scenario (cleared before each scenario is executed) in order to have the scenario state available to all step implementations executing in the same thread. But sometimes it is just cleaner, I think, to store state locally in fields in the step implementation class, as long as all the steps that need the info are located in the same class. Also, then I assume that the step class instances may be pooled and reused after a scenario has finished? If so, we have to be careful to not let the state leak over to the next scenario that happens to use that same instance. Or are steps class instances always recreated for each scenario execution? I’ll have to dig into our JBehave configuration a bit more to learn how this can be set up in our case. *From:*Mauro Talevi [mailto:mauro.tal...@aquilonia.org] *Sent:* den 7 september 2014 14:52 *To:* dev@jbehave.codehaus.org <mailto:dev@jbehave.codehaus.org> *Subject:* Re: [jbehave-dev] Step Class Instance Reuse? That depends how you configure your steps factory ... Sanity dictates that you ensure that the steps instances are unique (e.g. using the singleton mode of the dependency injection containers). Assuming this is true, then yes, the steps will always be executed from the same methods in the same class. Are you experiencing anything that may contradict this behaviour? On 07/09/2014 14:46, Anders wrote: Is it guaranteed that steps implemented in the same class will reuse the same step class instances when executed within the same scenario? Example: Scenario: My scenario Given step 1 When step 2 Then step 3 And step 4 Let’s say that step 1 and 2 are implemented in class A, and step 3 and 4 are implemented in class B. When this scenario is run, is it guaranteed that step 1 and 2 will be executed in the same instance of class A, and step 3 and 4 will be executed in the same instance of class B? - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] (JBEHAVE-1046) FailingUponPendingSteps strategy not honoured
Title: Message Title Mauro Talevi updated an issue JBehave / JBEHAVE-1046 FailingUponPendingSteps strategy not honoured Change By: Mauro Talevi Fix Version/s: 3.9.5 Summary: JBehave exits immaturely FailingUponPendingSteps strategy not honoured 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
Re: [jbehave-dev] Step Class Instance Reuse?
The steps classes are instantiated only once per run context, i.e. for the set of stories. The same steps classes are reused for all scenarios. A context object is the recommended way to hold state in a scenario, and you'd use a thread local if you are in multi-threading mode. If you need to reset the state before or after each scenario, you can do so via the @BeforeScenario and @AfterScenario annotations, or using the Lifecycle steps in your story. If you have a specific use case in mind, feel free to share it. On 07/09/2014 15:26, Anders wrote: Message Title No, no problem seen, and thanks for the quick reply. The reason I ask is just to know if the state of the steps class instance is guaranteed to be available during the whole scenario. We normally use a thread local singleton context manager to hold the state of the scenario (cleared before each scenario is executed) in order to have the scenario state available to all step implementations executing in the same thread. But sometimes it is just cleaner, I think, to store state locally in fields in the step implementation class, as long as all the steps that need the info are located in the same class. Also, then I assume that the step class instances may be pooled and reused after a scenario has finished? If so, we have to be careful to not let the state leak over to the next scenario that happens to use that same instance. Or are steps class instances always recreated for each scenario execution? I’ll have to dig into our JBehave configuration a bit more to learn how this can be set up in our case. *From:*Mauro Talevi [mailto:mauro.tal...@aquilonia.org] *Sent:* den 7 september 2014 14:52 *To:* dev@jbehave.codehaus.org <mailto:dev@jbehave.codehaus.org> *Subject:* Re: [jbehave-dev] Step Class Instance Reuse? That depends how you configure your steps factory ... Sanity dictates that you ensure that the steps instances are unique (e.g. using the singleton mode of the dependency injection containers). Assuming this is true, then yes, the steps will always be executed from the same methods in the same class. Are you experiencing anything that may contradict this behaviour? On 07/09/2014 14:46, Anders wrote: Is it guaranteed that steps implemented in the same class will reuse the same step class instances when executed within the same scenario? Example: Scenario: My scenario Given step 1 When step 2 Then step 3 And step 4 Let’s say that step 1 and 2 are implemented in class A, and step 3 and 4 are implemented in class B. When this scenario is run, is it guaranteed that step 1 and 2 will be executed in the same instance of class A, and step 3 and 4 will be executed in the same instance of class B?
Re: [jbehave-dev] Step Class Instance Reuse?
That depends how you configure your steps factory ... Sanity dictates that you ensure that the steps instances are unique (e.g. using the singleton mode of the dependency injection containers). Assuming this is true, then yes, the steps will always be executed from the same methods in the same class. Are you experiencing anything that may contradict this behaviour? On 07/09/2014 14:46, Anders wrote: Message Title Is it guaranteed that steps implemented in the same class will reuse the same step class instances when executed within the same scenario? Example: Scenario: My scenario Given step 1 When step 2 Then step 3 And step 4 Let’s say that step 1 and 2 are implemented in class A, and step 3 and 4 are implemented in class B. When this scenario is run, is it guaranteed that step 1 and 2 will be executed in the same instance of class A, and step 3 and 4 will be executed in the same instance of class B?
[jbehave-dev] [jira] (JBEHAVE-1045) Support for class-based AOP in step classes in Spring
Title: Message Title Mauro Talevi resolved an issue as Fixed JBehave / JBEHAVE-1045 Support for class-based AOP in step classes in Spring Change By: Mauro Talevi Resolution: Fixed Fix Version/s: 3.9.5 Status: Open Resolved 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-1045) Support for class-based AOP in step classes in Spring
Title: Message Title Mauro Talevi updated an issue JBehave / JBEHAVE-1045 Support for class-based AOP in step classes in Spring Change By: Mauro Talevi Affects Version/s: 4.0 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-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-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-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-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
Just be aware that you should not rely on any custom bean annotation.
All the beans in the context should be considered that have JBehave-annotated methods. So you should start from the method
@Override
protected List<Class> stepsTypes() {
List<Class> types = new ArrayList<Class>();
for (String name : context.getBeanDefinitionNames()) {
Class type = context.getType(name);
if (isAllowed(type) && hasAnnotatedMethods(type)) {
types.add(type);
}
}
return types;
}
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
[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 I see no reason to have a separate factory. AOP support could be added to the existing SpringStepsFactory. We can make it optional via a flag which is injected in the constructor. If you could provide a pull request with the appropriate changes, and a test case to verify it's functionality, it'd be greatly appreciated. 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
Re: [jbehave-dev] Blocking problem with JBehave eclipse plugin and large project (1900 testcases)
What is a testcase for you?
How many steps classes do you have?
You can add a debug logger level via the JBehave Preferences to see where the
bottleneck is.
BTW, Have you tried increasing the memory?
> On 1 Sep 2014, at 17:49, "Anders" wrote:
>
> The problem is that Eclipse becomes very slow and often hangs with a greyed
> out unresponsive GUI after that a story file or a step implementation file
> (Java file with Given/When/Then annotations) is edited.
> It is enough to type a few letters, no save required, for the
> unresponsiveness to start.
>
> We are using 32 bit Windows 7 for all developer work.
> (yes, it is just ridiculous that we are not allowed to use a 64 bit developer
> environment, so this is what we have to work with)
>
> Attached is a simple project that demonstrates the problem.
> Load this project up using Eclipse with the latest JBehave plugin, run the
> story generator, and then try to edit any story file or step implementation
> class, and enjoy the lag.
>
> Simply run the class GenerateStories to regenerate the stories and step
> implementation files.
> After this, refresh the project and it now contains 100 generated story
> files, each containing 10 scenarios with three steps each, and 100 step
> implementation classes / java files.
>
> The number of stories, scenarios and step implementation classes to be
> generated can be configured by changing the values of the constants below:
>
> public class GenerateStories {
>
> private final static String OUTPUT_PATH =
> "src/main/java/jbehave/stress";
> private final static String STORIES_OUTPUT_PATH = OUTPUT_PATH +
> "/usecases";
> private final static String STEPS_OUTPUT_PATH = OUTPUT_PATH +
> "/stepimpl";
>
> private final static int NUMBER_OF_USECASES = 100;
> private final static int NUMBER_OF_STORIES_PER_USECASE = 10;
> private final static int NUMBER_OF_SCENARIOS_PER_STORY = 10;
> private final static int NUMBER_OF_STEP_IMPLS_PER_JAVAFILE = 100;
> // must be same or higher than NUMBER_OF_USECASES for all steps to resolve
>
> . . .
>
>
> The current situation in our project is unbearable due to this.
> We have 1900 test cases running each night, and continuously have to keep the
> tests updated and add new tests each and every day.
>
> Maybe if someone can do some profiling on the plugin, and publishing the
> results would help the community to overcome this.
> Please help.
>
> /Anders
>
>
> -
> To unsubscribe from this list, please visit:
>
>http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] (JBEHAVE-1044) Multi-threading in scenarios & example tables
Title: Message Title Mauro Talevi commented on an issue Re: Multi-threading in scenarios & example tables No, the parametrised scenarios do not support multi-threading either. The executable boundary for concurrent execution is the story. Add Comment JBehave / JBEHAVE-1044 Multi-threading in scenarios & example tables We have many stories, and one story has 10-20 scenarios. It cost much time to run all of them by serial. I know JBehave support multi-threaded story execution capability, could you also support multi-threaded in scenario level and different data in example table? 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-1044) Multi-threading in scenarios & example tables
Title: Message Title Mauro Talevi commented on an issue Re: Multi-threading in scenarios & example tables Multi-threaded execution is only supported at story level. What do you mean by "different data in example table"? Please discuss these issues on the mailing lists: http://jbehave.org/mailing-lists.html Add Comment JBehave / JBEHAVE-1044 Multi-threading in scenarios & example tables We have many stories, and one story has 10-20 scenarios. It cost much time to run all of them by serial. I know JBehave support multi-threaded story execution capability, could you also support multi-threaded in scenario level and different data in example table? 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-scm] [scm-site][1/1] Updated page on how to report issues.
commit 4066095a38f242ef1adbbfcc65078aef8a57232d Author: Mauro Talevi AuthorDate: Mon, 25 Aug 2014 09:31:36 +0200 Commit: Mauro Talevi CommitDate: Mon, 25 Aug 2014 09:31:36 +0200 Updated page on how to report issues. diff --git a/site-frontend/src/site/content/how-to-contribute.html b/site-frontend/src/site/content/how-to-contribute.html index 70f98e9..35fa90a 100755 --- a/site-frontend/src/site/content/how-to-contribute.html +++ b/site-frontend/src/site/content/how-to-contribute.html @@ -16,13 +16,28 @@ Open a new issue on http://jira.codehaus.org/browse/JBEHAVE";>JIRA (a Codehaus login can be created at http://xircles.codehaus.org/projects/jbehave";>Xircles). Clone the http://github.com/jbehave";> GitHub repo of the appropriate project. -Commit your proposed changes to your clone repo, using the issue number that you created above in the commit message, i.e. start all commits with "JBEHAVE-xxx:". +Commit your proposed changes to your cloned repo, using the issue number that you created above in the commit message, i.e. start all commits with "JBEHAVE-xxx:". Update the issue with the links to the commits you made, which can be easily fetched and cherry-picked using git. For new ideas or solutions to your specific problems it is always recommended to first discuss them on the mailing-lists, where you can get the full benefit of the experience of the JBehave community. It may be that your problem can be already solved using existing functionality. +Reporting Issues + +Users' feedback on issues and bugs is essential and welcome but in order to be addressed and fixed, the issues need to be reproducible. + +To report an issue: + + +Open a new issue on http://jira.codehaus.org/browse/JBEHAVE";>JIRA. +Provide a self-contained sample project that reproduces your behaviour via command-line - preferably using Maven but other systems are fine too. +The sample project should be sharable either in an archive form (jar, tar, zip) or - preferably - via your own http://github.com";>GitHub repo. + + +Please avoid cutting & pasting or attaching bits of code and configuration to the JIRA issue as it makes it much more cumbersome to re-compose a +working project. +
[jbehave-dev] [jira] (JBEHAVE-1042) Support package scanning for annotated Steps classes
Title: Message Title Mauro Talevi updated an issue JBehave / JBEHAVE-1042 Support package scanning for annotated Steps classes Change By: Mauro Talevi Add ScanningStepsFactory implementation to retrieve and instantiate Steps classes by scanning configured packages and finding classes containing annotated methods. It can used programmatically or via the @UsingSteps annotation. Scanning will require optional org.reflections:reflections dependency. 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-1043) GivenStories are not working for me in jbehave-web-selenium [3.6-beta-2]
Title: Message Title Mauro Talevi commented on an issue Re: GivenStories are not working for me in jbehave-web-selenium [3.6-beta-2] Can you please provide a self-contained project reproducing the issue? http://jbehave.org/how-to-contribute.html Add Comment JBehave / JBEHAVE-1043 GivenStories are not working for me in jbehave-web-selenium [3.6-beta-2] Hi I am new in Jbehave and trying to setup automation framework using Jbehave[3.9.3] and selenium[2.42.2]. I am using Ivy to execute the test. I could able to do that successfully. GivenStories are not working for me. I am sorry if this is not the right place to ask this question. After trying for couple days and looking into the comments that Give... 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-scm] [scm-core/jbehave-4.0-beta-10][1/1] [maven-release-plugin] copy for tag jbehave-4.0-beta-10
Tag: jbehave-4.0-beta-10 (added) Type: annotated Commit: 7e40470b73e5dea875fc16acd023d68167ba0c56 Tagger: tag_info[:taggername] tag_info[:taggeremail] Message: [maven-release-plugin] copy for tag jbehave-4.0-beta-10
[jbehave-scm] [scm-core/jbehave-4.x][1/1] Updated release notes.
commit 73a552e73aef56237725b41a4bb3c421acde64d7 Author: Mauro Talevi AuthorDate: Sun, 24 Aug 2014 23:13:09 +0200 Commit: Mauro Talevi CommitDate: Sun, 24 Aug 2014 23:39:51 +0200 Updated release notes. diff --git a/distribution/src/site/content/release-notes.html b/distribution/src/site/content/release-notes.html index de2f8b2..c38985c 100755 --- a/distribution/src/site/content/release-notes.html +++ b/distribution/src/site/content/release-notes.html @@ -5,6 +5,29 @@ + +JBehave Core - Version 3.9.4 (Aug 24, 2014) + +Bug + + +[JBEHAVE-987] - Plugin execution not covered by lifecycle configuration + +[JBEHAVE-1037] - Story duration timeout occurs for not started story + +[JBEHAVE-1038] - Unable to resolve dependencies using ANT + + + +Improvement + + +[JBEHAVE-1041] - Allow StoryManager to calculate story durations + +[JBEHAVE-1042] - Support package scanning for annotated Steps classes + + + JBehave Core - Version 3.9.3 (Jun 19, 2014) Bug
[jbehave-scm] [scm-core/jbehave-3.9.4][1/1] [maven-release-plugin] copy for tag jbehave-3.9.4
Tag: jbehave-3.9.4 (added) Type: annotated Commit: 73ad41ecf5a70c3fa5bac7c1ce57d31877166d2d Tagger: tag_info[:taggername] tag_info[:taggeremail] Message: [maven-release-plugin] copy for tag jbehave-3.9.4
[jbehave-dev] [jira] (JBEHAVE-1041) Allow StoryManager to calculate story durations
Title: Message Title Mauro Talevi updated an issue JBehave / JBEHAVE-1041 Allow StoryManager to calculate story durations Change By: Mauro Talevi The story durations as calculated in the PostStoryStatisticsCollector are not reliable in multi-threading executions. The StoryManager should be responsible for their calculation. The duration (and hence the timeout) should be calculated from the start of the callable task and not the submission. 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-scm] [scm-core][1/1] Updated release notes.
commit 6b1113cc257a98cc7b57a3c47124cb3bad5461b0 Author: Mauro Talevi AuthorDate: Sun, 24 Aug 2014 23:13:09 +0200 Commit: Mauro Talevi CommitDate: Sun, 24 Aug 2014 23:13:09 +0200 Updated release notes. diff --git a/distribution/src/site/content/release-notes.html b/distribution/src/site/content/release-notes.html index de2f8b2..c38985c 100755 --- a/distribution/src/site/content/release-notes.html +++ b/distribution/src/site/content/release-notes.html @@ -5,6 +5,29 @@ + +JBehave Core - Version 3.9.4 (Aug 24, 2014) + +Bug + + +[JBEHAVE-987] - Plugin execution not covered by lifecycle configuration + +[JBEHAVE-1037] - Story duration timeout occurs for not started story + +[JBEHAVE-1038] - Unable to resolve dependencies using ANT + + + +Improvement + + +[JBEHAVE-1041] - Allow StoryManager to calculate story durations + +[JBEHAVE-1042] - Support package scanning for annotated Steps classes + + + JBehave Core - Version 3.9.3 (Jun 19, 2014) Bug
[jbehave-dev] [jira] (JBEHAVE-1037) Story duration timeout occurs for not started story
Title: Message Title Mauro Talevi updated an issue JBehave / JBEHAVE-1037 Story duration timeout occurs for not started story Change By: Mauro Talevi Fix Version/s: 3.9.4 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-1041) Allow StoryManager to calculate story durations
Title: Message Title Mauro Talevi updated an issue JBehave / JBEHAVE-1041 Allow StoryManager to calculate story durations Change By: Mauro Talevi The story durations as calculated in the PostStoryStatisticsCollector are not reliable in multi-threading executions. The StoryManager should be responsible for their calculation. The duration should be calculated from the start of the callable task and not the submission. 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-1037) Story duration timeout occurs for not started story
Title: Message Title Mauro Talevi resolved an issue as Fixed Fixed by JBEHAVE-1041 . JBehave / JBEHAVE-1037 Story duration timeout occurs for not started story Change By: Mauro Talevi Resolution: Fixed Assignee: Mauro Talevi Status: Open Resolved 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-1042) Support package scanning for annotated Steps classes
Title: Message Title Mauro Talevi resolved an issue as Fixed JBehave / JBEHAVE-1042 Support package scanning for annotated Steps classes Change By: Mauro Talevi Resolution: Fixed Status: Open Resolved 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-1042) Support package scanning for annotated Steps classes
Title: Message Title Mauro Talevi created an issue JBehave / JBEHAVE-1042 Support package scanning for annotated Steps classes Issue Type: Improvement Assignee: Mauro Talevi Created: 21/Aug/14 4:08 PM Fix Versions: 3.9.4 Priority: Minor Reporter: Mauro Talevi Add ScanningStepsFactory implementation to retrieve and instantiate Steps classes by scanning configured packages and finding classes containing annotated methods. Scanning will require optional org.reflections:reflections dependency. Add Comment This
[jbehave-dev] [jira] (JBEHAVE-1041) Allow StoryManager to calculate story durations
Title: Message Title Mauro Talevi resolved an issue as Fixed JBehave / JBEHAVE-1041 Allow StoryManager to calculate story durations Change By: Mauro Talevi Resolution: Fixed Status: Open Resolved 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-1041) Allow StoryManager to calculate story durations
Title: Message Title Mauro Talevi created an issue JBehave / JBEHAVE-1041 Allow StoryManager to calculate story durations Issue Type: Improvement Assignee: Mauro Talevi Created: 18/Aug/14 3:24 PM Fix Versions: 3.9.4 Priority: Major Reporter: Mauro Talevi The story durations as calculated in the PostStoryStatisticsCollector are not reliable in multi-threading executions. The StoryManager should be responsible for their calculation. Add Comment This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c
[jbehave-dev] [jira] (JBEHAVE-1037) Story duration timeout occurs for not started story
Title: Message Title Mauro Talevi commented on an issue Re: Story duration timeout occurs for not started story Is the time spent in the @Before methods such that it could account for the timeout? From the execution point of view, a story duration also includes all before and after steps, so if the before steps take a long time the "story" itself may not start at all. Could you please provide a sample project that reproduces this behaviour? Add Comment JBehave / JBEHAVE-1037 Story duration timeout occurs for not started story Some time (useStoryTimeoutInSecs) after starting my tests web browser is closed with warning" [WARNING] Story com/sample/qa/stories/login.story duration of 101 seconds has exceeded timeout of 100 seconds". No one executed story exceed this time. This is even before "login.story" execution. The clue is that the story contains all @Before and @After method... This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) - To unsubscribe from this
[jbehave-dev] [jira] (JBEHAVE-1039) Scenarios not allowed by filter are not skipped and cause NPEs
Title: Message Title Mauro Talevi resolved an issue as Fixed JBehave / JBEHAVE-1039 Scenarios not allowed by filter are not skipped and cause NPEs Change By: Mauro Talevi Resolution: Fixed Status: Open Resolved 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-1039) Scenarios not allowed by filter are not skipped and cause NPEs
Title: Message Title Mauro Talevi updated an issue JBehave / JBEHAVE-1039 Scenarios not allowed by filter are not skipped and cause NPEs Change By: Mauro Talevi Attachment: metatags.zip Only occurs in 4.x during the execution of the PerformableStory. 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-1039) Scenarios not allowed by filter are not skipped and cause NPEs
Title: Message Title Mauro Talevi created an issue JBehave / JBEHAVE-1039 Scenarios not allowed by filter are not skipped and cause NPEs Issue Type: Bug Assignee: Mauro Talevi Created: 16/Aug/14 8:38 AM Fix Versions: 4.0 Priority: Major Reporter: Mauro Talevi 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-1036) StoryReporterBuilder fails to parse test results if story has GivenStories
Title: Message Title
Mauro Talevi commented on an issue
Re: StoryReporterBuilder fails to parse test results if story has GivenStories
Rather than providing a set of morsels of code and configuration, it'd be much easier if you could provide a simple Maven sample project that reproduced this behaviour.
Add Comment
JBehave / JBEHAVE-1036
StoryReporterBuilder fails to parse test results if story has GivenStories
In case of story with GivenStories JBehave raport is broken. Although few scenarios has been successfully performed - "Scenarios" and "Steps" are missing. Duration is improperly set to zero. {code:title=Example of problematic story:|borderStyle=solid} @author Przemyslaw Kwiecien @organization Example Organization Systems Ltd. GivenStorie...
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-1037) Story duration timeout occurs for not started story
Title: Message Title Mauro Talevi commented on an issue Re: Story duration timeout occurs for not started story Does this occur with 3.9.x as well? Add Comment JBehave / JBEHAVE-1037 Story duration timeout occurs for not started story Some time (useStoryTimeoutInSecs) after starting my tests web browser is closed with warning" [WARNING] Story com/sample/qa/stories/login.story duration of 101 seconds has exceeded timeout of 100 seconds". No one executed story exceed this time. This is even before "login.story" execution. The clue is that the story contains all @Before and @After method... 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-1038) Unable to resolve dependencies using ANT
Title: Message Title Mauro Talevi resolved an issue as Fixed Applied URL changed as suggested, with thanks. JBehave / JBEHAVE-1038 Unable to resolve dependencies using ANT Change By: Mauro Talevi Resolution: Fixed Assignee: Mauro Talevi Status: Open Resolved 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-scm] [scm-core/jbehave-4.x][1/1] JBEHAVE-1038: Changed Atlassian URL.
commit 77c5c62ea28a003571d6bec4669f5ae7d5e9f09b Author: Mauro Talevi AuthorDate: Fri, 15 Aug 2014 15:06:43 +0200 Commit: Mauro Talevi CommitDate: Fri, 15 Aug 2014 15:07:26 +0200 JBEHAVE-1038: Changed Atlassian URL. diff --git a/settings.xml b/settings.xml index 528f62c..f99454e 100755 --- a/settings.xml +++ b/settings.xml @@ -49,13 +49,13 @@ atlassian - http://maven.atlassian.com/public + https://maven.atlassian.com/content/groups/public/ atlassian - http://maven.atlassian.com/public + https://maven.atlassian.com/content/groups/public/
[jbehave-scm] [scm-core][1/1] JBEHAVE-1038: Changed Atlassian URL.
commit a1f244008e3d6d9dcdf949615fda55239be39b9d Author: Mauro Talevi AuthorDate: Fri, 15 Aug 2014 15:06:43 +0200 Commit: Mauro Talevi CommitDate: Fri, 15 Aug 2014 15:06:43 +0200 JBEHAVE-1038: Changed Atlassian URL. diff --git a/settings.xml b/settings.xml index 528f62c..f99454e 100755 --- a/settings.xml +++ b/settings.xml @@ -49,13 +49,13 @@ atlassian - http://maven.atlassian.com/public + https://maven.atlassian.com/content/groups/public/ atlassian - http://maven.atlassian.com/public + https://maven.atlassian.com/content/groups/public/
[jbehave-dev] [jira] (JBEHAVE-1038) Unable to resolve dependencies using ANT
Title: Message Title Mauro Talevi updated an issue JBehave / JBEHAVE-1038 Unable to resolve dependencies using ANT Change By: Mauro Talevi Affects Version/s: 4.x Fix Version/s: 3.9.4 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
Re: [jbehave-dev] skip scenario based on tags
Hi Ajay Thanks for the project. I was able to reproduce the problem which is in effect present when using filters with the 4.0 code base. Need to look into it to find the root cause. In the meantime you can use latest 3.9.x release. Cheers, M > On 14 Aug 2014, at 02:00, अजय सिंह wrote: > > > Hi Mauro, > Thanks for your reply > Please find the project attached > > Thanks > Ajay > > >> On Wed, Aug 13, 2014 at 5:01 PM, Mauro Talevi >> wrote: >> The error does not seem related to meta filters. But you'll need to >> provide a way for us to reproduce the issue because it's not possible to >> help you otherwise. >> >> Can you share your Maven project reproducing the behaviour? >> >> >>> On 13/08/2014 01:56, अजय सिंह wrote: >>> >>> >>> Hi I have three scenario and i would like to run scenarios in different env >>> based on the tags. >>> >>> I have tagged my 3 scenario as >>> >>> @env SIT [to run in SIT] //.scenario1 >>> @env QA [to run in QA] //.scenario2 >>> @env SITQA [to run in both]//.scenario3 >>> >>> and in my meta filter i use >>> -env QA >>> >>> With these i get following exceptions [logs attached] >>> (BeforeStories) >>> >>> [INFO] Running story org/test/sample/stories/my.story >>> >>> (org/test/sample/stories/my.story) >>> Scenario: this scenario should run in SIT >>> Given I am a SIT step >>> >>> Scenario: this scenario should run in QA >>> [WARNING] Failed to run story org/test/sample/stories/my.story >>> org.jbehave.core.failures.UUIDExceptionWrapper: >>> java.lang.NullPointerException >>> at >>> org.jbehave.core.embedder.PerformableTree.perform(PerformableTree.java:366) >>> at >>> org.jbehave.core.embedder.StoryManager$EnqueuedStory.call(StoryManager.java:238) >>> at >>> org.jbehave.core.embedder.StoryManager$EnqueuedStory.call(StoryManager.java:217) >>> at java.util.concurrent.FutureTask.run(FutureTask.java:262) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>> at java.lang.Thread.run(Thread.java:745) >>> >>> >>> >>> Can anyone explain me whats wrong or how can i achieve this including >>> excluding scenario based on tags ? >>> >>> Thanks >>> Ajay >>> >>> >>> >>> - >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email > > > > - > To unsubscribe from this list, please visit: > >http://xircles.codehaus.org/manage_email
Re: [jbehave-dev] skip scenario based on tags
The error does not seem related to meta filters. But you'll need to provide a way for us to reproduce the issue because it's not possible to help you otherwise. Can you share your Maven project reproducing the behaviour? On 13/08/2014 01:56, ??? wrote: Hi I have three scenario and i would like to run scenarios in different env based on the tags. I have tagged my 3 scenario as @env SIT [to run in SIT] //.scenario1 @env QA [to run in QA] //.scenario2 @env SITQA [to run in both]//.scenario3 and in my meta filter i use *-env QA* With these i get following exceptions [logs attached] /(BeforeStories)/ / / /[INFO] Running story org/test/sample/stories/my.story/ / / /(org/test/sample/stories/my.story)/ /Scenario: this scenario should run in SIT/ /Given I am a SIT step/ / / /Scenario: this scenario should run in QA/ /[WARNING] Failed to run story org/test/sample/stories/my.story/ /org.jbehave.core.failures.UUIDExceptionWrapper: java.lang.NullPointerException/ /at org.jbehave.core.embedder.PerformableTree.perform(PerformableTree.java:366)/ /at org.jbehave.core.embedder.StoryManager$EnqueuedStory.call(StoryManager.java:238)/ /at org.jbehave.core.embedder.StoryManager$EnqueuedStory.call(StoryManager.java:217)/ /at java.util.concurrent.FutureTask.run(FutureTask.java:262)/ /at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)/ /at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)/ /at java.lang.Thread.run(Thread.java:745)/ Can anyone explain me whats wrong or how can i achieve this including excluding scenario based on tags ? Thanks Ajay - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] (JBEHAVE-712) Spaces in path breaks StoryFinder().findPaths()
Title: Message Title
Mauro Talevi commented on an issue
Re: Spaces in path breaks StoryFinder().findPaths()
Can you provide an example or a unit test reproducing the problem?
Add Comment
JBehave / JBEHAVE-712
Spaces in path breaks StoryFinder().findPaths()
Constructions like: List storyPaths = new StoryFinder().findPaths(codeLocationFromClass(getClass()), "**/*.story", "**/*examples.story"); or List storyPaths = new StoryFinder().findPaths(codeLocationFromPath("somePath"), "**/*.story", "**/*examples.story"); doesn't work when there are spaces in a path (which are replaced to %20). An...
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
Re: [jbehave-dev] ThreadLocal in FluentWebDriverPage
Hi, if you have time to provide and test such a contribution, it'd be most welcome.If so, please raise a JIRA issue and add a link to a pull request in github. Yes, it'd be better to separate the thread management functionality into different class(es) that can then be easily reused in steps classes (e.g. annotated per-story or per-scenario). Equally, this thread management functionality could also be used by the implementations of the providers. Thanks for your input and help. Cheers On 31/07/2014 20:07, Emanuel Campolo wrote: Hi Mauro , Im not experiencing any articular issue but it's not a good idea to have those instances attached to a thread since memory leaks are plausible. Moreover, if you inspect those FluentWebDriver instances they keep the instance of the WebDriver object even after the end() method is called. (I think it is something that has to do with the garbage collector and weak references). We should also consider the scenario where multiple threads create a large amount of page objects. The number of page objects and therefore, the FluentWebDriver instances would increase considerably. A FluentLifecycleSteps class is a good idea. Also, the provider could have a reference to a class thats if responsible to keep track of the threads locals instances that are created. This class could use the unique thread id value in a map. Maybe the provider is doing too much. We should delegate how we store resources (either WebDriver of FluentWebDriver instances) and how we eliminate them. 2014-07-31 14:12 GMT-03:00 Mauro Talevi <mailto:mauro.tal...@aquilonia.org>>: Hi Emanuel, thanks for providing this example. The one WebDriver instance is correctly managed in the WebDriverProvider.end() method. The FluentWebDriver instances are not managed in the same way - they are not WebDriver instances and there is no lifecycle management. There is an instance created for each page, each using the same WebDriver instance as delegate. I'm not sure this constitutes a memory leak, simply that the instances are not removed at the end of the story execution. But that could easily apply to other objects as well. Are you experiencing any specific issues as a consequence of this?If so, I'd would add a FluentLifecycleSteps class method that finds the ThreadLocal instances of FluentWebDriver and nullifies them, and we can annotate it @AfterStory. Cheers On 30/07/2014 21:39, Emanuel Campolo wrote: Hi Mauro, I could reproduce the memory leak. To do that, I created a project from the jbehave-web archetype and made the some modifications in order to get some logs. I also refactored some of the page objects since the default test cases had some errors due to etsy home page modifications. This is the project: https://github.com/emacampolo/etsy-jbehave/tree/jbehave-web-possible-memory-leak And this is the class that prints the logs: https://github.com/emacampolo/etsy-jbehave/blob/jbehave-web-possible-memory-leak/src/main/java/org/jbehave/tutorials/etsy/steps/JournaledStoriesSteps.java Below you can find the output (I print all the ThreadLocal instances that are subclasses of WebDriver or FluentWebDriver). *Narrative:* *In order to show the browsing cart functionality* *As a user* *I want to browse in a gallery* *Scenario: Browsing around the site for items* *LOGGING BEFORE SCENARIO* * * *Thread name: main* *DoublyOverriddenFirefoxDriver: firefox on LINUX (eea68437-dfb6-4783-9ebf-d3b2c95c9f28)* *Given I am on etsy.com <http://etsy.com>* *When I want to browse through an art gallery* *When I want to buy something from etsy.com <http://etsy.com>* *When I want to browse the Art* *When I choose the first art gallery* *Then results will be displayed in the gallery* * * *LOGGING BEFORE CALLING END()* * * *Thread name: main* *org.seleniumhq.selenium.fluent.FluentWebDriver@1570e827* *Thread name: main* *org.seleniumhq.selenium.fluent.FluentWebDriver@27996370* *Thread name: main* *org.seleniumhq.selenium.fluent.FluentWebDriver@474f625f* *Thread name: main* *org.seleniumhq.selenium.fluent.FluentWebDriver@2cc36f8c* *Thread name: main* *DoublyOverriddenFirefoxDriver: firefox on LINUX (eea68437-dfb6-4783-9ebf-d3b2c95c9f28)* * * *[INFO] 2 stories excluded by filter: +category browsing* * * * * *(AfterStories)* *LOGGING AFTER STORIES* * * *Thread name: main* *org.seleniumhq.selenium.fluent.Fl
Re: [jbehave-dev] ThreadLocal in FluentWebDriverPage
Hi Emanuel,
thanks for providing this example. The one WebDriver instance is
correctly managed in the WebDriverProvider.end() method.
The FluentWebDriver instances are not managed in the same way - they are
not WebDriver instances and there is no lifecycle management. There
is an instance created for each page, each using the same WebDriver
instance as delegate.
I'm not sure this constitutes a memory leak, simply that the instances
are not removed at the end of the story execution. But that could
easily apply to other objects as well.
Are you experiencing any specific issues as a consequence of this?If
so, I'd would add a FluentLifecycleSteps class method that finds the
ThreadLocal instances of FluentWebDriver and nullifies them, and we can
annotate it @AfterStory.
Cheers
On 30/07/2014 21:39, Emanuel Campolo wrote:
Hi Mauro,
I could reproduce the memory leak. To do that, I created a project
from the jbehave-web archetype and made the some modifications in
order to get some logs.
I also refactored some of the page objects since the default test
cases had some errors due to etsy home page modifications.
This is the project:
https://github.com/emacampolo/etsy-jbehave/tree/jbehave-web-possible-memory-leak
And this is the class that prints the logs:
https://github.com/emacampolo/etsy-jbehave/blob/jbehave-web-possible-memory-leak/src/main/java/org/jbehave/tutorials/etsy/steps/JournaledStoriesSteps.java
Below you can find the output (I print all the ThreadLocal instances
that are subclasses of WebDriver or FluentWebDriver).
*Narrative:*
*In order to show the browsing cart functionality*
*As a user*
*I want to browse in a gallery*
*Scenario: Browsing around the site for items*
*LOGGING BEFORE SCENARIO*
*
*
*Thread name: main*
*DoublyOverriddenFirefoxDriver: firefox on LINUX
(eea68437-dfb6-4783-9ebf-d3b2c95c9f28)*
*Given I am on etsy.com <http://etsy.com>*
*When I want to browse through an art gallery*
*When I want to buy something from etsy.com <http://etsy.com>*
*When I want to browse the Art*
*When I choose the first art gallery*
*Then results will be displayed in the gallery*
*
*
*LOGGING BEFORE CALLING END()*
*
*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@1570e827*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@27996370*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@474f625f*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@2cc36f8c*
*Thread name: main*
*DoublyOverriddenFirefoxDriver: firefox on LINUX
(eea68437-dfb6-4783-9ebf-d3b2c95c9f28)*
*
*
*[INFO] 2 stories excluded by filter: +category browsing*
*
*
*
*
*(AfterStories)*
*LOGGING AFTER STORIES*
*
*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@1570e827*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@27996370*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@474f625f*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@2cc36f8c*
As you can see, by the time the suite is over, there are 4
FluentWebDriver instances (one for each page object that is created)
attached to the current thread.
On the other hand, you may notice that the
*DoublyOverriddenFirefoxDriver *is removed correctly.
There are a couple of approaches to solve this. First, let's validate
this issue.
Note: If you want to run it, please use the following filter since the
other test cases seems not to be working
mvn clean install -Dmeta.filter="+category browsing"
2014-07-30 13:47 GMT-03:00 Mauro Talevi <mailto:mauro.tal...@aquilonia.org>>:
It's your right to use alternative implementations, but at least
the interfaces should be the same and the maven dependencies declared.
If you find there's a bug in an implementation, the best way to
address it is to provide a same project that reproduces it and
perhaps a patch for it.
On 30/07/2014 18:21, Emanuel Campolo wrote:
Please dont get me wrong. I do want to help. I've copied some
classes because i found out that I could have memory leak issues
using the FluentWebDriverPage.
I will send you some logs using a newly created project with the
jbehave-web archetype.
On Jul 30, 2014 1:09 PM, "Mauro Talevi"
mailto:mauro.tal...@aquilonia.org>>
wrote:
It seems to me that you're not even using jbehave-web.
You've copied selected classes from it into your project and
using them in a way which is different from jbehave-web, e.g.
introducing another factory abstraction.
If you'd help on using jbehave-we
Re: [jbehave-dev] ThreadLocal in FluentWebDriverPage
It's your right to use alternative implementations, but at least the interfaces should be the same and the maven dependencies declared. If you find there's a bug in an implementation, the best way to address it is to provide a same project that reproduces it and perhaps a patch for it. On 30/07/2014 18:21, Emanuel Campolo wrote: Please dont get me wrong. I do want to help. I've copied some classes because i found out that I could have memory leak issues using the FluentWebDriverPage. I will send you some logs using a newly created project with the jbehave-web archetype. On Jul 30, 2014 1:09 PM, "Mauro Talevi" <mailto:mauro.tal...@aquilonia.org>> wrote: It seems to me that you're not even using jbehave-web. You've copied selected classes from it into your project and using them in a way which is different from jbehave-web, e.g. introducing another factory abstraction. If you'd help on using jbehave-web, including resolving issues with its current implementation, we'd be happy to help. If you're writing your own framework, then we can't help. Cheers On 30/07/2014 17:52, Emanuel Campolo wrote: Hi Mauro, thanks for taking your time to reply. I mentioned PerStoryWebDriverSteps as an example of how the framework cleans up the resources. In this case, when the end() method is invoked, the ThreadLocal instance associated with the current thread is removed but, if you'd used a FluentWebDriverPage instead of a WebDriverPage, a ThreadLocal will not be eliminated from the list of thread locals. Even though im not using the jbehave-core for running my tests, Im coding a lightweight selenium-based framework using testng and the jbehave-web project. As you can see below, I had to re write some of the classes to solve this issue where resources are not being removed by the DelegatingWebDriverProvider (javadoc and reference to jbehave-web will be added): https://github.com/emacampolo/hatchery/blob/master/src/main/java/com/hatchery/core/DefaultWebDriverProvider.java https://github.com/emacampolo/hatchery/blob/master/src/main/java/com/hatchery/core/pages/FluentWebDriverPage.java This is where I invoke the end() method https://github.com/emacampolo/hatchery/blob/master/src/main/java/com/hatchery/core/Suite.java 2014-07-30 12:06 GMT-03:00 Mauro Talevi mailto:mauro.tal...@aquilonia.org>>: Hi, the FluentWebDriverPage is simply a fluent-based facade using a FluentWebDriver. The underlying WebDriverProvider is the same as a non-fluent page and is injected in the constructor. The PerStoryWebDriverSteps should use exactly the same underlying WebDriverProvider (autowired via some dependency-injection mechanism), so if the provider end() method is invoked you shouldn't need to do anything else. Are you experiencing or noticing a particular problem? If so, could you share a project that reproduced it? Cheers On 29/07/2014 19:14, Emanuel Campolo wrote: Hi all ! I've added the jbehave-web module to a personal project where I use testng. I'm using the FirefoxWebDriverProvider to manage the webdriver instances, taking advantage of the ThreadLocal for multithreaded tests. My question is, even though I call the end() method every time a test completes to remove the driver assigned to the current thread, i don't know how to the same thing to the FluentWebDriver (a thread local variable that the FluentWebDriverPage has). I noticed that , for example, the PerStoryWebDriverSteps only executes driverProvider.end() but as in mentioned above, i didn't find any clean up for the FluentWebDriver instances that FluentWebDriverPage creates. Thanks in advance :) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [jbehave-dev] ThreadLocal in FluentWebDriverPage
It seems to me that you're not even using jbehave-web. You've copied selected classes from it into your project and using them in a way which is different from jbehave-web, e.g. introducing another factory abstraction. If you'd help on using jbehave-web, including resolving issues with its current implementation, we'd be happy to help. If you're writing your own framework, then we can't help. Cheers On 30/07/2014 17:52, Emanuel Campolo wrote: Hi Mauro, thanks for taking your time to reply. I mentioned PerStoryWebDriverSteps as an example of how the framework cleans up the resources. In this case, when the end() method is invoked, the ThreadLocal instance associated with the current thread is removed but, if you'd used a FluentWebDriverPage instead of a WebDriverPage, a ThreadLocal will not be eliminated from the list of thread locals. Even though im not using the jbehave-core for running my tests, Im coding a lightweight selenium-based framework using testng and the jbehave-web project. As you can see below, I had to re write some of the classes to solve this issue where resources are not being removed by the DelegatingWebDriverProvider (javadoc and reference to jbehave-web will be added): https://github.com/emacampolo/hatchery/blob/master/src/main/java/com/hatchery/core/DefaultWebDriverProvider.java https://github.com/emacampolo/hatchery/blob/master/src/main/java/com/hatchery/core/pages/FluentWebDriverPage.java This is where I invoke the end() method https://github.com/emacampolo/hatchery/blob/master/src/main/java/com/hatchery/core/Suite.java 2014-07-30 12:06 GMT-03:00 Mauro Talevi <mailto:mauro.tal...@aquilonia.org>>: Hi, the FluentWebDriverPage is simply a fluent-based facade using a FluentWebDriver. The underlying WebDriverProvider is the same as a non-fluent page and is injected in the constructor. The PerStoryWebDriverSteps should use exactly the same underlying WebDriverProvider (autowired via some dependency-injection mechanism), so if the provider end() method is invoked you shouldn't need to do anything else. Are you experiencing or noticing a particular problem? If so, could you share a project that reproduced it? Cheers On 29/07/2014 19:14, Emanuel Campolo wrote: Hi all ! I've added the jbehave-web module to a personal project where I use testng. I'm using the FirefoxWebDriverProvider to manage the webdriver instances, taking advantage of the ThreadLocal for multithreaded tests. My question is, even though I call the end() method every time a test completes to remove the driver assigned to the current thread, i don't know how to the same thing to the FluentWebDriver (a thread local variable that the FluentWebDriverPage has). I noticed that , for example, the PerStoryWebDriverSteps only executes driverProvider.end() but as in mentioned above, i didn't find any clean up for the FluentWebDriver instances that FluentWebDriverPage creates. Thanks in advance :) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [jbehave-dev] ThreadLocal in FluentWebDriverPage
Hi, the FluentWebDriverPage is simply a fluent-based facade using a FluentWebDriver. The underlying WebDriverProvider is the same as a non-fluent page and is injected in the constructor. The PerStoryWebDriverSteps should use exactly the same underlying WebDriverProvider (autowired via some dependency-injection mechanism), so if the provider end() method is invoked you shouldn't need to do anything else. Are you experiencing or noticing a particular problem? If so, could you share a project that reproduced it? Cheers On 29/07/2014 19:14, Emanuel Campolo wrote: Hi all ! I've added the jbehave-web module to a personal project where I use testng. I'm using the FirefoxWebDriverProvider to manage the webdriver instances, taking advantage of the ThreadLocal for multithreaded tests. My question is, even though I call the end() method every time a test completes to remove the driver assigned to the current thread, i don't know how to the same thing to the FluentWebDriver (a thread local variable that the FluentWebDriverPage has). I noticed that , for example, the PerStoryWebDriverSteps only executes driverProvider.end() but as in mentioned above, i didn't find any clean up for the FluentWebDriver instances that FluentWebDriverPage creates. Thanks in advance :) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] (JBEHAVE-1035) @BeforeStory steps not performed before GivenStories
Title: Message Title Mauro Talevi resolved an issue as Fixed JBehave / JBEHAVE-1035 @BeforeStory steps not performed before GivenStories Change By: Mauro Talevi Resolution: Fixed Assignee: Mauro Talevi Status: Open Resolved 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-1035) @BeforeStory steps not performed before GivenStories
Title: Message Title
Mauro Talevi commented on an issue
Re: @BeforeStory steps not performed before GivenStories
4.0-beta-9 has been released.
4.0-SNAPSHOT has also been deployed. The deployment is not automatic as yet because we need to find a way of securing the credentials on the CI server.
Add Comment
JBehave / JBEHAVE-1035
@BeforeStory steps not performed before GivenStories
There seems to be a bug in 4.0-beta-8 concerning the usage of GivenStories. If I have a story which uses "GivenStories" then I get this exception: {noformat} org.jbehave.web.selenium.DelegatingWebDriverProvider$DelegateWebDriverNotFound: WebDriver has not been found for this thread. Please verify you are using the correct WebDriverProvider, with t...
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-1035) @BeforeStory steps not performed before GivenStories
Title: Message Title Mauro Talevi updated an issue JBehave / JBEHAVE-1035 @BeforeStory steps not performed before GivenStories Change By: Mauro Talevi Affects Version/s: web-3.5.5 Affects Version/s: 4.x Fix Version/s: 4.x Fix Version/s: 4.0 Summary: DelegateWebDriverNotFound: WebDriver has @BeforeStory steps not been found for this thread. performed before GivenStories 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-scm] [scm-core/jbehave-4.0-beta-9][1/1] [maven-release-plugin] copy for tag jbehave-4.0-beta-9
Tag: jbehave-4.0-beta-9 (added) Type: annotated Commit: 356c1c1d85692ea90de467bc8cb22d0afcea8c83 Tagger: tag_info[:taggername] tag_info[:taggeremail] Message: [maven-release-plugin] copy for tag jbehave-4.0-beta-9
[jbehave-dev] [jira] (JBEHAVE-1035) DelegateWebDriverNotFound: WebDriver has not been found for this thread.
Title: Message Title
Mauro Talevi commented on an issue
Re: DelegateWebDriverNotFound: WebDriver has not been found for this thread.
Please pull latest 4.x and try out snapshot.
Add Comment
JBehave / JBEHAVE-1035
DelegateWebDriverNotFound: WebDriver has not been found for this thread.
There seems to be a bug in 4.0-beta-8 concerning the usage of GivenStories. If I have a story which uses "GivenStories" then I get this exception: {noformat} org.jbehave.web.selenium.DelegatingWebDriverProvider$DelegateWebDriverNotFound: WebDriver has not been found for this thread. Please verify you are using the correct WebDriverProvider, with t...
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-scm] [scm-core/jbehave-4.x][1/1] JBEHAVE-1035: Ensure @BeforeStory steps are performed before the GivenStories.
commit c2f1548f0d48a301fed36d33208ab84fa62efeb5
Author: Mauro Talevi
AuthorDate: Mon, 28 Jul 2014 18:05:43 +0100
Commit: Mauro Talevi
CommitDate: Mon, 28 Jul 2014 18:05:43 +0100
JBEHAVE-1035: Ensure @BeforeStory steps are performed before the
GivenStories.
diff --git
a/jbehave-core/src/main/java/org/jbehave/core/embedder/PerformableTree.java
b/jbehave-core/src/main/java/org/jbehave/core/embedder/PerformableTree.java
index 6a2345e..3247b10 100644
--- a/jbehave-core/src/main/java/org/jbehave/core/embedder/PerformableTree.java
+++ b/jbehave-core/src/main/java/org/jbehave/core/embedder/PerformableTree.java
@@ -715,8 +715,10 @@ public class PerformableTree {
State state = context.state();
Timer timer = new Timer().start();
try {
+beforeSteps.perform(context);
performGivenStories(context);
performScenarios(context);
+afterSteps.perform(context);
} finally {
timing.setDurationInMillis(timer.stop());
}
@@ -735,11 +737,9 @@ public class PerformableTree {
}
private void performScenarios(RunContext context) throws
InterruptedException {
-beforeSteps.perform(context);
for (PerformableScenario scenario : scenarios) {
scenario.perform(context);
}
-afterSteps.perform(context);
}
public List getScenarios() {
[jbehave-dev] [jira] (JBEHAVE-1035) DelegateWebDriverNotFound: WebDriver has not been found for this thread.
Title: Message Title
Mauro Talevi commented on an issue
Re: DelegateWebDriverNotFound: WebDriver has not been found for this thread.
Does it happen only with GivenStories?
Add Comment
JBehave / JBEHAVE-1035
DelegateWebDriverNotFound: WebDriver has not been found for this thread.
There seems to be a bug in 4.0-beta-8 concerning the usage of GivenStories. If I have a story which uses "GivenStories" then I get this exception: {noformat} org.jbehave.web.selenium.DelegatingWebDriverProvider$DelegateWebDriverNotFound: WebDriver has not been found for this thread. Please verify you are using the correct WebDriverProvider, with t...
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-1033) Add JiraMetaMatcher
Title: Message Title Mauro Talevi created an issue JBehave / JBEHAVE-1033 Add JiraMetaMatcher Issue Type: New Feature Assignee: Unassigned Components: REST Support Created: 12/Jul/14 2:17 AM Fix Versions: 3.9.4 Priority: Major Reporter: Mauro Talevi A MetaMatcher that looks up a JIRA issue via REST and allows the meta if the issue is open. Add Comment
[jbehave-dev] [jira] (JBEHAVE-1032) Allow MetaMatcher to be injectable
Title: Message Title Mauro Talevi created an issue JBehave / JBEHAVE-1032 Allow MetaMatcher to be injectable Issue Type: Improvement Assignee: Mauro Talevi Components: Core Created: 12/Jul/14 2:15 AM Fix Versions: 3.9.4 Priority: Major Reporter: Mauro Talevi To support custom implementations and extensibility of the meta matching, the MetaMatcher should be injectable and default to the implementations provided in core if not injected. Add Comment
Re: [jbehave-dev] jbehave plugin configuration
This should be easily achieved by providing the user the ability to
specify the custom locale from a free-text field rather than from the
pre-defined list. As long as it's in the classpath it will be picked up.
Please raise a JIRA issue for this.
On 10/07/2014 20:25, fernando guallini wrote:
I think the same Brent. I use the JBehave keywords in Spanish (custom
language, in fact), but the Eclipse plugin does not support the
Spanish language or custom.
2014-07-10 14:50 GMT-03:00 Brent Barker <mailto:brentbark...@gmail.com>>:
This would be a really nice feature to have.
On Tue, Jul 8, 2014 at 8:34 AM, Frank Pedroza mailto:fpedr...@part.net>> wrote:
Custom story language... for example, I want to define
different Strings as my comments
On Tue, Jul 8, 2014 at 7:42 AM, Mauro Talevi
mailto:mauro.tal...@aquilonia.org>> wrote:
You've not answered my question.
What do you mean by a custom language?
On 8 Jul 2014, at 15:37, fernando guallini
mailto:fer.wa...@gmail.com>> wrote:
I have the same issue, Is there a way to configure
eclipse plugin with a customize language?
2014-07-08 3:57 GMT-03:00 Mauro Talevi
mailto:mauro.tal...@aquilonia.org>>:
Preferences > JBehave > Project Settings > Story
Language drop-down list
Or do you mean to support another language than the
one in the list?
On 07/07/2014 21:05, Frank Pedroza wrote:
Is it possible to configure the JBehave eclipse
plugin to use a different/customize 'Story Language'?
http://jbehave.org/eclipse-integration.html
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Frank M. Pedroza - Software Engineer
Partnet - Development
801.708.5050
-
The nice part about being a pessimist is that you are
constantly being either proven right or pleasantly surprised.
-- George F. Will
Re: [jbehave-dev] jbehave plugin configuration
You've not answered my question. What do you mean by a custom language? > On 8 Jul 2014, at 15:37, fernando guallini wrote: > > I have the same issue, Is there a way to configure eclipse plugin with a > customize language? > > > 2014-07-08 3:57 GMT-03:00 Mauro Talevi : >> Preferences > JBehave > Project Settings > Story Language drop-down list >> >> Or do you mean to support another language than the one in the list? >> >> >>> On 07/07/2014 21:05, Frank Pedroza wrote: >>> Is it possible to configure the JBehave eclipse plugin to use a >>> different/customize 'Story Language'? >>> >>> http://jbehave.org/eclipse-integration.html >> >> >> - >> To unsubscribe from this list, please visit: >> >>http://xircles.codehaus.org/manage_email >
[jbehave-dev] [jira] (JBEHAVE-961) Customize JBehave HTML report.
Title: Message Title Mauro Talevi commented on an issue Re: Customize JBehave HTML report. Currently, users can provide their own meta properties. We could allow these to also be read from other sources, e.g. env variables. Add Comment JBehave / JBEHAVE-961 Customize JBehave HTML report. Is there any way to customize HTML the way we want in JBehave? As per our project requirement, we want to add more information in HTML report such as date time, browser tested etc. We noticed HTMLoutput method in JBehave. If it is possible with this method can you please provide any good example? 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
