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 > <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] > <mailto:[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] >> <mailto:[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
