Plugin Unit Testing

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.

Thanks Carlos.

Yes, the process model tests would check to see if the plugin works as a whole, but I was after something more fine granular (aka unit testing in Java)

Thanks Carlos.

Yes, the process model tests would check to see if the plugin works as a whole, but I was after something more fine granular (aka unit testing in Java)

A year and a half later, 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.