Unit Testing of plugin code

You can do that the same way you test any plug-in, all you need is:

1. A local Appian installation
2. Add <APPIAN_HOME>\\_admin\\_scripts\\classpath.jar to the build path
3. When initializing the unit testing invoke

ConfigurationLoader.initializeConfigurations();

For example

@Before
public void setUp() throws Exception {
ConfigurationLoader.initializeConfigurations();
}

then start from there.

Hi Eduardo,
Is there are a recommended alternative to the approach you described? The ConfigurationLoader.initializeConfigurations() method is currently marked as Deprecated.
Regards,
Philip

This might not be sufficient for your case, but one way to think about a plugin is as a two-piece component: the actual functionality and an integration layer. You can create jUnit tests for the functionality piece of the plugin (for example, communicating with an external service), but the integration layer would be tested by writing test rules/test process models in Appian.

Hi Carlos. Thank you for the reply but that is not going to achieve what I have in mind. I will continue my search. Thanks!

Ok, I thought you were still asking about unit testing, whereas you're now asking about a different approach to using the deprecated initializeConfigurations. The documentation states that using the service API from a standalone application is no longer supported, so you could still create unittests for logic that doesn't depend on Appian services. Alternatively, you could create mocks for the Appian services that you would use in the tests.

Yes, I am actually looking for a way to run automated regression testing for the Appian plugins we are implementing. Integration testing with other systems is not an issue at this point. Thanks.

As a senior developer responsible for creating a plugin standard across all projects, I struggle with this.
Some developers will use and pass Appian specific services into nearly every important or critical method in most classes.

When asked to rebrand an altered plugin, it's practically impossible, within a reasonable amount of time, to decouple the Appian specific code and the actual workhorses of the plugin. This is generally due to downloaded plugins and plugins developed in-house due, specifically, to the lack of standards.

Carlos is right, plugins are a two piece project. The plugin code itself, the pom, and you should be using Maven, would call a separate library to do the actual heavy lifting and the Plugin project is simply an integration wrapper.

With ConfigurationLoader.initializeConfiguration being deprecated, we need a way to mock Appian services to support legacy or upgraded plugins without the need to spend an inordinate amount of time trying to split it apart.

As a senior developer responsible for creating a plugin standard across all projects, I struggle with this.
Some developers will use and pass Appian specific services into nearly every important or critical method in most classes.

When asked to rebrand an altered plugin, it's practically impossible, within a reasonable amount of time, to decouple the Appian specific code and the actual workhorses of the plugin. This is generally due to downloaded plugins and plugins developed in-house due, specifically, to the lack of standards.

Carlos is right, plugins are a two piece project. The plugin code itself, the pom, and you should be using Maven, would call a separate library to do the actual heavy lifting and the Plugin project is simply an integration wrapper.

With ConfigurationLoader.initializeConfiguration being deprecated, we need a way to mock Appian services to support legacy or upgraded plugins without the need to spend an inordinate amount of time trying to split it apart.