Questions:
1) How are your running the stories, IDE or CLI (Maven or Ant)?
2) If you are running by CLI you can set meta-filter via a configurable
property: e.g.
https://github.com/jbehave/jbehave-core/blob/master/examples/trader/pom.xml
And you can run:
mvn clean install -Dmeta.filter="+tag value"
You can also use annotations to set meta filters on the class:
http://jbehave.org/reference/stable/meta-filtering.html
Cheers
On 19/11/2012 13:00, Ola Sundell wrote:
Well, it's a bit of a long story, but here goes:
We have a website which is based around a content management system.
The web templates that we use are very dynamic and change quite alot
depending on content and the way that our editors publish it. Our
ambition is to automate web visitor tests for all relevant browsers
and all relevant visitor patterns. It's a daunting task, to be honest.
Currently, we're doing almost all of these tests manually, but
currently we are automating manual tests quicker than we're
constructing new stuff to test. As the number of our automated tests
grow, so does the need for structure.
Enter BDD. ;)
We have already written a framework around Selenium, partly to provide
a Command pattern style interface for finding and/or changing content
in our tests, but mostly to circumvent the frailty and the poor
performance that is inherent in Selenium. The framework uses Spring to
keep track of browsers and it requires that every test extends a
class, which in turn extends SeleneseTestBase.
We'll hopefully open source the relevant parts of the framework
before christmas. Therefore, unfortunately we cannot simply rewrite
everything from scratch and do stuff the JBehave way.
We have to solve two needs: We need to use said framework. We also
need to keep all our stories in one or at most a few Google Drive
spreadsheets, otherwise we'll quickly lose track of what's tested
where. This presented us with a dilemma: how can a developer run one
and only one scenario, as described by the Java code he's working on?
Hopefully, we've solved it in our semi-hack of an Embedder:
protected Embeddable embeddable = null;
<snip>
@Override
public InjectableStepsFactory stepsFactory() {
if (embeddable != null) {
return new InstanceStepsFactory(configuration(),
embeddable);
}
return new SpringStepsFactory(configuration(), applicationContext);
}
<snip>
and our abstract base test class, which implements Embeddable:
@Test
public void run() throws Throwable {
embedder.setEmbeddable(this);
embedder.runStoriesAsPaths(Arrays.asList(...));
}
Currently I'm looking at using Meta filters to filter out all but the
current scenario, so we'll avoid all the PENDING fluff around the
actual scenario, but it's not incredibly important. I noticed the line
of code in Embedder.java and I thought I was looking at a bug.
We're probably doing all of this a bit ass-backwards...I'm looking
forward to a "why don't you do it -this- way instead?" kind of mail. :)
Ola
Från: Mauro Talevi <[email protected]>
Till: "[email protected]" <[email protected]>
Datum: 2012/11/19 12:01
Ärende: Re: [jbehave-dev] Overriding metaFilter() in my own Embedder.
------------------------------------------------------------------------
Hi Ola,
can you not make use of the useMetaFilters method in the Embedder to
set the meta filters?
Can you share what you're trying to do and how?
Please raise a jira issue for the google API upgrade with a link to
the patch on GitHub.
Cheers
PS: Thanks for your expression of support. Much appreciated!
On 19 Nov 2012, at 11:23, Ola Sundell <[email protected]_
<mailto:[email protected]>> wrote:
Hello and thanks for JBehave, a wonderful library!
I am trying to override metaFilter() in my own Embedder, but the 3.7.3
code looks like this, from Embedder.java, rows 422-424:
public MetaFilter metaFilter() {
return new MetaFilter(StringUtils.join(metaFilters, " "),
embedderMonitor);
}
Shouldn't it be
return new MetaFilter(StringUtils.join(metaFilters(), " "),
embedderMonitor());
instead? It would be far easier to extend...I would be overjoyed if
this found its way into 3.7.4!
Oh, and btw: I've written my own hack for Google Drive which uses the
newer Google APIs, including OAuth2 and google-api-services-drive
instead of the old, deprecated stuff that you guys have. I can share
it on Github if you're interested (and my employer thinks it's a good
idea, which I am so certain of that I assume it).
Thanks,
Ola
