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 <mauro.tal...@aquilonia.org>
Till:
"dev@jbehave.codehaus.org" <dev@jbehave.codehaus.org>
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 <ola.sund...@svt.se> 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
