Tim, That doesn’t mean there isn’t room for improvement. If you have an ideas of how you would like it to work, or how it would work well, please create a Jira issue.
On April 30, 2018 at 23:40:36, Tim Dean ([email protected]) wrote: Thank you for the information, Otto. If this approach is how the core NiFi services are tested, I guess it is appropriate for my custom services. -Tim On Apr 27, 2018, at 4:25 PM, Otto Fowler <[email protected]> wrote: /* * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package org.apache.nifi.lookup; import java.util.ArrayList; import java.util.List; import org.apache.nifi.components.PropertyDescriptor; import org.apache.nifi.processor.AbstractProcessor; import org.apache.nifi.processor.ProcessContext; import org.apache.nifi.processor.ProcessSession; import org.apache.nifi.processor.exception.ProcessException; public class TestProcessor extends AbstractProcessor { @Override public void onTrigger(ProcessContext context, ProcessSession session) throws ProcessException { } @Override protected List<PropertyDescriptor> getSupportedPropertyDescriptors() { List<PropertyDescriptor> properties = new ArrayList<>(); properties.add(new PropertyDescriptor.Builder() .name("LookupService test processor") .description("LookupService test processor") .identifiesControllerService(LookupService.class) .required(true) .build()); return properties; } } On April 27, 2018 at 17:25:26, Otto Fowler ([email protected]) wrote: That is the way that the Standard Controller Services that have tests work. On April 27, 2018 at 17:12:21, Tim Dean ([email protected]) wrote: The NiFi developer documentation does a good job of describing how to unit test custom processors, including how to configure a controller service that the processor depends on. However, it doesn’t provide information on how to best unit test a custom controller service. The biggest challenge I am having is that my controller service has a couple of properties that need to be configured in order to test them. The TestRunner class has the ability to add a controller service and to set its properties, but in order to create a test runner I need a processor that uses the controller service. There doesn’t seem to be a way to create a test runner that is just used for a controller service. We’ve been working around this is to create a processor that depends on the controller service, then create a TestRunner for that processor, then create an instance of the controller service and apply it to the test runner, then use the test runner to set its properties. Is this the only way to do this? It feels like a bit of a hack if I am creating a controller service that is for another team’s processor’s to use. As a result I don’t always have my own processor that depends on the controller service I want to test. I can of course create one artificially for the purposes of testing, but that seems like a lot of extra work just to test my service controller. Thanks, -Tim
