[jira] [Created] (NIFI-4776) Test suite behavioral differences

["Mikhail Sosonkin (JIRA)" <ji...@apache.org>]

Mikhail Sosonkin created NIFI-4776:
--------------------------------------

             Summary: Test suite behavioral differences
                 Key: NIFI-4776
                 URL: https://issues.apache.org/jira/browse/NIFI-4776
             Project: Apache NiFi
          Issue Type: Bug
            Reporter: Mikhail Sosonkin


I think there might a difference in behavior for how processor attributes are evaluated in the test suite vs real execution. I'm not entirely sure if it is an expected/acceptable behavior. It has to do with the DATA_SIZE_VALIDATOR. Mine was defined as follows:
 
    public static final PropertyDescriptor MAX_ROW_SIZE = new PropertyDescriptor
        .Builder().name(BigQueryAttributes.MAX_ROW_SIZE_ATTR)
        .displayName("Max row size")
        .description(BigQueryAttributes.MAX_ROW_SIZE_DESC)
        .required(true)
        .defaultValue("1 MB")
        .addValidator(StandardValidators.DATA_SIZE_VALIDATOR)
        .build();
 
Then I would use it like this in the onTrigger method:
 
    final long max_row_size = context.getProperty(MAX_ROW_SIZE).asLong();
 
I used it this way based on the examples I've seen in the other processors. In the runtime it seems to be working great and gives me the byte values. However, in testing it would throw an exception because it would try to parse "1 MB" (the default value) as an actual Long. Of course, if I just place a long value (like 1024) it would not pass the validation function. So, I did a more explicit "cast" using the asDataSize method:
 
    final long max_row_size = context.getProperty(MAX_ROW_SIZE).asDataSize(DataUnit.B).longValue();
 
This solved my problems and makes the code a bit more explicit which is nice. The annoying part is that the StandardProcessorTestRunner does not keep the stacktrace from the exceptions generated in onTrigger of the processor (StandardProcessorTestRunner:199)
 
   final Throwable thrown = future.get();
 
That is what caused confusion for me. I hadn't realized that the exception was being thrown via my code. So, if anything the test suite needs to do a better job at delivering stack traces for the exceptions to help with debugging. Depending on what you decide, there might be two tasks here.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)