James try it with a throwable like in my example
On Thu, Aug 23, 2018 at 10:51 AM Mark Payne <marka...@hotmail.com> wrote:
> James,
>
> If you are expecting the method to throw an Exception and want to verify
> that, you should
> just call the method directly from your unit test and catch the Exception
> there. The TestRunner
> expects to run the full lifecycle of the Processor.
>
> Thanks
> -Mark
>
>
> > On Aug 23, 2018, at 10:49 AM, James Srinivasan <
> james.sriniva...@gmail.com> wrote:
> >
> > I tried that, but the problem is the exception is caught and the test
> > fails due to this:
> >
> > try {
> > ReflectionUtils.invokeMethodsWithAnnotation(OnScheduled.class,
> > processor, context);
> > } catch (final Exception e) {
> > e.printStackTrace();
> > Assert.fail("Could not invoke methods annotated with @OnScheduled
> > annotation due to: " + e);
> > }
> >
> >
> https://github.com/apache/nifi/blob/master/nifi-mock/src/main/java/org/apache/nifi/util/StandardProcessorTestRunner.java#L181
> > On Thu, 23 Aug 2018 at 15:41, Mike Thomsen <mikerthom...@gmail.com>
> wrote:
> >>
> >> For unit tests, if you're doing this to catch a failure scenario, you
> >> should be able to wrap the failing call in something like this:
> >>
> >> final def msg = "Lorem ipsum..."
> >> def error = null
> >> try {
> >> runner.run()
> >> } catch (Throwable t) {
> >> error = t
> >> } finally {
> >> assertNotNull(error)
> >> assertTrue(error.cause instanceof SomeException)
> >> assertTrue(error.cause.message.contains(msg))
> >> }
> >>
> >> Obviously play around with the finally block, but I've had success with
> >> that pattern.
> >>
> >> On Thu, Aug 23, 2018 at 10:19 AM James Srinivasan <
> >> james.sriniva...@gmail.com> wrote:
> >>
> >>> What is the best way to handle exceptions which might be thrown in my
> >>> @OnScheduled method? Right now, I'm logging and propagating the
> >>> exception which has the desired behaviour in NiFi (bulletin in GUI and
> >>> processor cannot be started) but when trying to add a unit test, the
> >>> (expected) exception is caught in StandardProcessorTestRunner.run and
> >>> failure asserted.
> >>>
> >>> My actual @OnScheduled method builds a non-trivial object based on the
> >>> Processor's params - maybe I should be building that any time any of
> >>> the params change instead?
> >>>
> >>> Many thanks,
> >>>
> >>> James
> >>>
>
>
