While creating new scenarios I only want to test the scenario I am currently working with. For this purpose I want to use the Meta: #skip tag before my scenarios. As I found out I have to use the embedder to configure the used meta tags, so I tried:
configuredEmbedder().useMetaFilters(Arrays.asList("-skip"));
but actually this still has no effect on my test scenarios
But now I get the message [pool-1-thread-1] INFO net.serenitybdd.core.Serenity - TEST IGNORED but the scenario is still executed. Only in the result page I get the info that this scenario is ignored (but still executed). Is there a way to SKIP the scenario so it won't run?
Here is my scenario description Meta: #skip Given something When something Then something
Try with the latest version of serenity-bdd since there is an implementation which is related to your query. refer this.
Related
the context of the problem is like this: we create workflows, we save it and after a while a new implementation request comes and we change an activity. After this the workflow instances that were saved cannot run anymore. We get this error:
StateMachine Error : Cannot convert object 'True' to type 'System.String'.
It seems that the new argument added brakes the serialization order?
You'll have to implement Dynamic Update in some fashion.
We are currently in the process of getting some infrastructure set up to update existing instances, and having lots of issues. Hopefully your scenario is easier to solve than ours!
Start here: https://msdn.microsoft.com/en-us/library/hh314052(v=vs.110).aspx
Word of caution: I've found various issues with Microsoft's provided code that required a lot of investigation to fix.
In JBehave, BeforeStory or AfterStory annotation can be added in Step level. So if there are multiple Steps classes with BeforeStory annotation, all those BeforeStory annotated methods will be executed before the each and every story start (which is not needed).
In JUnit we can add or leave BeforeClass or Before as needed in test classes separately. So what I need is a way to add BeforeStory or AfterStory in a story level just like JUnit test class.
Is there a way to add BeforeStory as a lifecycle in a story file ? or any alternative solution ?
Following example shows only adding Before in the lifecycle.
http://jbehave.org/reference/stable/story-syntax.html
Lifecycle:
Before:
Given a step that is executed before each scenario
After:
Outcome: ANY
Given a step that is executed after each scenario regardless of outcome
Outcome: SUCCESS
Given a step that is executed after each successful scenario
Outcome: FAILURE
Given a step that is executed after each failed scenario
Thanks.
In my opinion jbehave does not have such a facility as of now. But try the following - in the class file execute a Given to initialize users and in the end of the story scenarios define another Given to release resources. I know this approach breaks the BDD paradigm of whole and business defined scenarios, but atleast is a work around.
To ensure it executes first and last you could use (priority=1) for initUsers() and (priority=n) for cleanup().
As you have quoted from the documentation, Before and After steps are executed after each scenario and not step as was stated. There is no facility to have a 'before story' step defined in a story file.
An alternative to define something in a story file is to annotate method with #BeforeStory as described in: http://jbehave.org/reference/stable/annotations.html
I am in a process of implementing Page object Model, I have one query regarding it, please see below:
I have created page files which is having locators and methods for the page, I have spec file in which I am doing the assertions by calling these methods. My question is that for one page I have over 100 test cases, now should I create single assertion file for single tests or should I create 100 assertion file for 100 test.
Please let me know what is the best way to manage it.
Regards,
Manan
I think it makes the most sense to group tests into files by functionality. It's hard to run only some tests from a file, so split out any groups of tests you think you might want to run independently. Are some of them suitable for a quick smoke test suite? Maybe those should be in a separate file.
You shouldn't need to create a new file for neither every assertion nor test case. I am confused by your question because in my understanding, the assertion is part of the test case, and test+assertion are part of the same function (assertion being the end goal of the test).
Regarding the Page Object Model: The important part of the pattern is ensuring the separation of page/DOM detail from test flow (i.e. tests should possess no knowledge of the DOM, but instead rely on page objects to act on actual pages).
I have many scenarios with Examples. In case of failure for an "Example", JBehave stop executing the scenario for remaining list of examples. e.g.
Given a record with classification
When I view the page
Then I see the record has type
Examples:
|classification|type|
|classification_1|type_1|
|classification_2|type_2|
|classification_3|type_3|
|classification_4|type_4|
If the scenario fails for
|classification_2|type_2|
then it will not execute 3 and 4.
Is there a way to configure JBehave to execute all the examples even in cas of failures?
Thanks.
After debugging with JBehave source code, looks like it is not possible. In StoryRunner class, in case of failure it uses instance of "SomethingHappened implements State" which doesn't look at any strategy just does the following:
StepResult result = step.doNotPerform(scenarioFailure);
result.describeTo(reporter.get());
Hence we see step NOT PERFORMED in the report.
I wish I'm wrong and somebody more knowledgeable can correct me.
This seems to be similar to a post I have just answered. Please check your configuration. More information can be found here
JBehave : How to ignore failure in scenario
I am trying to use Windows Workflow and have a model that looks similar to the image in the link below:
After each of the Send Activities (GetSomthing, GetSomthingElse, GetSomeMoreStuff) the same custom activity is being called (LogSomthingBadHappened).
While it might not look so bad in this picture in my real model the custom activity is a SequenceActivty, has quite a few nodes, and when its repeated 3 times starts to make the workflow look very ugly.
I would like to do something like this:
Can the IfElse branches be merged like this?
Should I be using a State Machine work flow instead (haven't figured these out yet)?
Use a FaultHandler on the workflow and throw a specific exception type that the handler will catch. Not the most graceful, but I think it should work.
In sequential workflows all steps must appear in a specific order, and the execution path is regulated exclusively by control structures (IF, WHILE).Altering the execution path in the way you describe would be like using a GOTO statement in imperative code, which we know leads to unnecessary complexity.
If the activities contained in the SequenceActivity that you need to execute at different stages of your workflow are exacty the same, you could embed them in a custom activity. This way it is easier to manage them since they are contained in a single logical unit.In imperative code, this would be like refactoring out a portion of duplicated code into a method, which is then invoked multiple places.
Another alternative that might work is to put your LogSomthingBadHappened activity into a custom workflow and include that several time. Several things to watch out for: Subworkflow are executed asynchronously, if the LogSomthingBadHappened activity needs state information from the main workflow, copying it to the sub workflow might be hard.
I have not tried this, so it might not even work.
I think the answer by gbanfill points to the right direction.
To generalize, I define the problem as:
Is there a way to define a group of activities that will be executed in several places of a workflow?
Further requirements are:
The group of activities should be defined in XAML only ie no code.
Type of input to this group will, of course, be fixed but actual values should depend on call (like calling a function).
Maybe the way to do it is define sub-workflows and build a custom activity that would instantiate the sub-workflow and wait for it to complete before continuing.
This custom activity should have at least two parameters: the sub-workflow id and input parameters.