Russ, Your init() method should be getting called when you create the TestRunner using your processor instance. It calls Processor.initialize() and AbstractSessionFactoryProcessor's implementation calls its own protected init() method (which is what I'm assuming you've overridden). It also calls any methods that were annotated as @OnAdded and @OnConfigurationRestored. These could be split out if necessary, or organized such as TestRunner's methods are. TestRunner has some overloaded methods for run, the "base" one is:
public void run(final int iterations, final boolean stopOnFinish, final boolean initialize, final long runWait) If you call run() with no parameters, you'll get 1 iteration that "initializes" and stops on finish (with a 5 second run-wait). However specifying "initialize" as true just invokes any methods with an @OnScheduled annotation. For your use case, if you keep a reference to your instance of MyProcessor, you can call your @OnScheduled method explicitly (not via TestRunner), then perform your assertions, etc. Then if you want to run onTrigger() but you don't want to reinitialize, you can do: runner.run(1, true, false) which says to run once, stop on finish, and don't initialize. There are a couple examples of manipulating the run() methods in CaptureChangeMySQLTest [1]. If you'd like to see the initialize() and other stuff split out from the TestRunner instantiation, please feel free to file a Jira for the improvement. Regards, Matt [1] https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-cdc/nifi-cdc-mysql-bundle/nifi-cdc-mysql-processors/src/test/groovy/org/apache/nifi/cdc/mysql/processors/CaptureChangeMySQLTest.groovy On Tue, May 23, 2017 at 5:20 PM, Russell Bateman <[email protected]> wrote: > I wondered if it were possible to split the firing of MyProcessor.init()out > of TestRunner.run()so that I have finer granularity in testing? Maybe I'm > abusing init()by what I'm doing in it, but I'd like to see that run and give > control back to my test case for some assertions and other things, before > moving on. In fact, it would be nice to have granularity for > @OnScheduledmethods that way, maybe others too. > > TestRunner runner = TestRunners( new MyProcessor() ); > runner.setProperty(), etc. > runner.enqueue(), etc. > *runner.init(), etc.** > **runner.onScheduled(), etc.* > runner.run( 1 ); > > Did I miss a turn somewhere and this is already supported? I've pored > through the test framework Javadoc and missed it? > > Russ >
