I 'inherited' the tests with the recent failures and the departure of the
original author. We are still on 3.1.2 as some of the tests fail when we
upgrade to anything newer than that. What I've heard is that the tests
used to run fine on 2.x and then required some hacks to get working on
3.1.2 as 3.x apparently initializes data and tests differently.
What I have done is to wrap the stories in something similar to the
TraderStoryRunner example, remove the maven plugin calls and have it
execute as part of the junit tests. Doing this the same tests that pass
using 3.1.2 via maven, fails.
The story file for this specific test is 2430 lines of text, about 21000+
JBehave steps. I will try to give as much relevant information as I can,
but due to the commercial nature of the software I'm limited as to what I
can share.
I have the following base class which is supposed to set up the JBehave
specifics:
import static org.jbehave.core.io.CodeLocations.codeLocationFromClass;
import java.util.List;
import java.util.Properties;
import org.jbehave.core.configuration.Configuration;
import org.jbehave.core.configuration.MostUsefulConfiguration;
import org.jbehave.core.embedder.Embedder;
import org.jbehave.core.embedder.EmbedderControls;
import org.jbehave.core.io.StoryFinder;
import org.jbehave.core.parsers.RegexPrefixCapturingPatternParser;
import org.jbehave.core.reporters.CrossReference;
import org.jbehave.core.reporters.Format;
import org.jbehave.core.reporters.StoryReporterBuilder;
import org.jbehave.core.steps.InjectableStepsFactory;
import org.jbehave.core.steps.InstanceStepsFactory;
import org.jbehave.core.steps.SilentStepMonitor;
public class BaseJBehaveRunner
{
protected void testJBehaveStory(String story_name, Object... steps)
{
Embedder embedder = createEmbedder();
setStepsFactory(embedder, steps);
List<String> storyPaths = new StoryFinder().findPaths(
codeLocationFromClass(this.getClass()), "**/" + story_name,"");
System.out.println (storyPaths);
try
{
embedder.runStoriesAsPaths(storyPaths);
}
finally
{
embedder.generateCrossReference();
}
}
private void setStepsFactory(Embedder embedder, Object... steps)
{
InjectableStepsFactory factory = new InstanceStepsFactory(
embedder.configuration(),
steps);
embedder.useStepsFactory(factory);
// embedder.useCandidateSteps(factory.createCandidateSteps());
// embedder.reportMatchingStepdocs("Given WAREHOUSE receipt offset
handling");
}
private Embedder createEmbedder()
{
Embedder embedder = new Embedder();
Properties rendering = new Properties();
rendering.put("decorateNonHtml", "true");
Configuration configuration = new MostUsefulConfiguration()
.useStoryReporterBuilder(new StoryReporterBuilder()
.withDefaultFormats()
.withViewResources(rendering)
.withFormats(Format.TXT, Format.HTML, Format.XML)
.withFailureTrace(false)
.withCrossReference(new CrossReference()))
.useStepMonitor(new SilentStepMonitor())
.useStepPatternParser(new RegexPrefixCapturingPatternParser("%"));
embedder.useConfiguration(configuration);
EmbedderControls controls = new EmbedderControls().
doIgnoreFailureInStories(true).
doBatch(false).
doIgnoreFailureInView(false).
doGenerateViewAfterStories(true);
embedder.useEmbedderControls(controls);
return embedder;
}
}
This is extended by the actual test. The @SuppressStaticInitializationFor
is necessary to bypass a library's need to load a windows dynamic library.
This library is used through the code to perform error and event logging
so it is too difficult to code around:
import org.junit.Test;
import org.junit.runner.RunWith;
import
org.powermock.core.classloader.annotations.SuppressStaticInitializationFor;
import org.powermock.modules.junit4.PowerMockRunner;
import
postilion.services.extract.ssb.clearance.integration.ach.scenarios.steps.CompanyNameSteps;
import
postilion.services.extract.ssb.clearance.integration.ach.scenarios.steps.EffectiveDateSteps;
@RunWith(PowerMockRunner.class)
@SuppressStaticInitializationFor({"postilion.office.OfficeLib"})
public class TestCompanyNameJBehave extends BaseJBehaveRunner
{
@Test
public void testCompanyNameStory()
{
testJBehaveStory("company_name.story", new CompanyNameSteps());
}
@Test
public void testEffectiveDateStory()
{
testJBehaveStory("effective_date.story", new EffectiveDateSteps());
}
}
The code implementing the steps uses a @BeforeStory method to initialize
the data used in the tests. It also has a @BeforeScenario that clears some
of the data before every scenario. The different @Given methods will set
values on the instance data, the @When method will execute business logic
on the actual instance data and store the results. The @Then methods will
depending on the parameters passed in, perform some actions on the results
and then do JUnit and hamcrest assertions on it.
It would appear that when jbehave is upgraded or when I move to the maven
agnostic junit implementation, that the actual initialization of the data
changes for some tests and the logic now operates on different input data.
Please let me know if you need any more information or more of the code.
Alwyn Schoeman
On Sat, Sep 29, 2012 at 6:07 AM, Mauro Talevi <mauro.tal...@aquilonia.org>wrote:
> Can you provide a sample project showing what you're trying to achieve?
>
> In general, keep in mind that JBehave does not aim to do unit-level
> testing and mocking. The maven plugin is a completely independent way of
> running the stories from say the JUnit framework.
>
> Moreover, any reason why you're still on 3.1.2 and not upgrading to the
> latest stable version?
>
> Cheers
>
>
> On 28/09/2012 21:34, Alwyn Schoeman wrote:
>
>> Hi everyone,
>>
>> I need to use Powermock to suppress static initialization of some classes
>> used by my JBehave tests. Currently the tests are executed by using the
>> run-as-embeddables goal of the maven plugin.
>>
>> Have tried just adding the @RunWith(PowerMockRunner.**class) to the
>> existing stories that extend JUnitStory with no success.
>>
>> Have tried removing the maven plugin dependency and embedding the stories
>> in standard JUnit tests that is then executed by Surefire. This works as
>> far as PowerMockRunner goes, but for some reason result in some test
>> failures.
>>
>> These same test failures also happen when I upgrade the jbehave core from
>> the current 3.1.2 to 3.6.9.
>>
>> I did not write the stories, they are very complex and I don't know if
>> these failures with newer jbehave versions are due to the specific tests
>> being faulty or not.
>>
>> Is there a way that I can introduce PowerMockRunner into the equation
>> while still using the Maven jbehave plugin and version 3.1.2 of jbehave?
>>
>> Regards,
>> Alwyn Schoeman
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe from this list, please visit:
>
>
> http://xircles.codehaus.org/**manage_email<http://xircles.codehaus.org/manage_email>
>
>
>
