Thanks very much, I'm now able to write a useful unit test to catch
the expected exception. Given the great support I've had from the
list, I'll start my organisation's process to contribute the code back
for this:
https://jira.apache.org/jira/browse/NIFI-5538
On Fri, 24 Aug 2018 at 16:41, Mark P
James,
Yes, makes perfect sense. I think that's a good balance of logic, as well. Use
a validator to quickly
ensure that the file exists. Then, when trying to use it, go ahead and parse
the data and set your
member variable. You could have the validator parse the file (but not set the
member va
Mark,
Thanks very much for the detailed answer. In my particular case, I
have a parameter corresponding to a schema file on disk and there is a
standard validator to ensure that the file exists. Currently, in my
@OnScheduled method, I read that schema file, parse it and store the
parsed results in
James,
You can certainly catch Throwable there, or AssertionError, more specifically,
but I'd be very wary
of doing that, because at that point you're really kind of working against the
framework (both the
nifi mock/test framework as well as the JUnit framework) instead of with it. If
your inte
Ah, hadn't spotted that. It's close, but the Throwable I get is a
java.lang.AssertionError (Could not invoke methods annotated with
@OnScheduled annotation due to:
java.lang.reflect.InvocationTargetException) and there doesn't seem to
be any way to get the actual underlying exception my code threw
James try it with a throwable like in my example
On Thu, Aug 23, 2018 at 10:51 AM Mark Payne 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 Tes
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, Jam
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 @OnSchedu
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(e
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 c
10 matches
Mail list logo
