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 <[email protected]> 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
> <[email protected]>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 <
>> [email protected]> 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 <[email protected]> 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 <
>>> [email protected]> 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 <[email protected]> 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
>>>
>>> -----------------------------------------------------------------
>>> 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
>>
>>
>>
>
>
> --
> --------------------------------------------
> 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
>
