That was the default story reporter, which is now deprecated in favour
of the story reporter builder.
On 13/05/2014 14:04, Paul Hammant wrote:
Isn't there also useStoryReporter()?
Like so:
public Configuration getConfiguration()
{
return new MostUsefulConfiguration()
.useStoryParser(new GherkinStoryParser())
.useStoryControls(
new StoryControls()
.doDryRun(TestConfiguration.getInstance().doDryRun())
.doSkipScenariosAfterFailure(false))
.useStepPatternParser(new RegexPrefixCapturingPatternParser())
.useStoryLoader(new LoadFromClasspath(this.getClass().getClassLoader()))
.useStoryReporter(
new StoryReporter() {
// OP implements methods here..
});
}
On Tue, May 13, 2014 at 7:23 AM, Frank Pedroza <fpedr...@part.net
<mailto:fpedr...@part.net>> wrote:
The key appears to have been related to the StoryReporter.
public Configuration getConfiguration()
{
return new MostUsefulConfiguration()
.useStoryParser(new GherkinStoryParser())
.useStoryControls(
new StoryControls()
.doDryRun(TestConfiguration.getInstance().doDryRun())
.doSkipScenariosAfterFailure(false))
.useStepPatternParser(new RegexPrefixCapturingPatternParser())
.useStoryLoader(new
LoadFromClasspath(this.getClass().getClassLoader()))
.useStoryReporterBuilder(
new StoryReporterBuilder()
.withFormats(Format.CONSOLE, Format.TXT, Format.STATS)
.withFailureTrace(true)
.withReporters(new LogginStoryReporter(LOG)));
}
class LogginStoryReporter
extends NullStoryReporter
{
private final Logger logger;
public LogginStoryReporter(Logger logger) {
this.logger = logger;
}
@Override
public void failed(String step, Throwable cause) {
logger.error("{} (FAILED)", step, cause);
}
@Override
public void failedOutcomes(String step, OutcomesTable table) {
failed(step, table.failureCause());
StringBuilder message = new StringBuilder();
message.append("(Failed Outcomes) ").append(step);
for (Outcome<?> out : table.getFailedOutcomes()) {
message.append(out.getDescription());
}
logger.error(message.toString());
}
}
On Mon, May 12, 2014 at 4:08 PM, Mauro Talevi
<mauro.tal...@aquilonia.org <mailto:mauro.tal...@aquilonia.org>>
wrote:
Can you be a bit more specific please. An example?
On 12/05/2014 20:48, Frank Pedroza wrote:
I'm attempting to capture where in a story is during a story
run as well as any stacks that are showing up in the console,
but not my log file.
On Mon, May 12, 2014 at 12:41 PM, Mauro Talevi
<mauro.tal...@aquilonia.org
<mailto:mauro.tal...@aquilonia.org>> wrote:
All components - including monitors - are configurable so
you can swap the default with your own:
http://jbehave.org/reference/stable/configuration.html
What use case are you trying to satisfy? Having say
debug-level logging being always written to a file in the
background?
On 12 May 2014, at 19:21, Frank Pedroza
<fpedr...@part.net <mailto:fpedr...@part.net>> wrote:
Could you help me understand this a bit more or point me
to something that explains how I would configure the
jbehave framework to support this?
On Fri, May 9, 2014 at 4:12 PM, Mauro Talevi
<mauro.tal...@aquilonia.org
<mailto:mauro.tal...@aquilonia.org>> wrote:
JBehave uses the monitor pattern that allows you to
honour dependency injection properly. Most logging
frameworks rely on static lookup mechanisms.
If you want to use a logging framework you can still
do so by providing a logging implementation of the
relevant interfaces.
Cheers
> On 9 May 2014, at 22:09, Frank Pedroza
<fpedr...@part.net <mailto:fpedr...@part.net>> wrote:
>
> I'm new to the group so sorry if this isn't the
right venue for this sort of question or if this has
already been addressed, but why is any of the
JBehave framework using System.out rather than
something like slf4j?
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
--------------------------------------------
Frank M. Pedroza - Software Engineer
Partnet - Development
801.708.5050 <tel: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
--
--------------------------------------------
Frank M. Pedroza - Software Engineer
Partnet - Development
801.708.5050 <tel: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
--
--------------------------------------------
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
