One of the biggest problems when testing a NiFi processor that connects to a remote resource is that we don't want to actually connect to some remote resource from a unit test. We can stand up a simple server ourselves in the unit test and configure the Processor to communicate with it, but then we have to understand and implement the server-specific specification and may not be able to properly send back error messages, etc. that we would like for testing.

Generally, the approach taken here is to have a method in the Processor that is responsible for obtaining a connection or a client to a remote resource. We generally mark this method as protected. In the unit test, instead of creating the TestRunner by calling TestRunners.newTestRunner(Class) and providing the Processor class, we instead create a subclass of the Processor in our unit test and use this:

@Test
public void testConnectionFailure() {
 final TestRunner runner = TestRunners.newTestRunner(new MyProcessor() {
 protected Client getClient() {
 // Return a mocked out client here.
 return new Client() {
 public void connect() throws IOException {
 throw new IOException();
 }

 // ...
 // other client methods
 // ...
 };
 }
 });

 // rest of unit test.
}

This allows us to implement a Client that mocks out all of the network communications and returns the different error results that we want to test, as well as ensure that our logic is correct for handling successful calls to the client.