It would indeed be best to be able to construct a real ThirdPartyObject.
Since you need to refer to this class, you have at least some 3rd party library on your class path that contains this class. Are you sure there's no way to construct it, e.g. using a factory which is also in the library? Or by constructing another object and calling a method that will call your plugin with a ThirdPartyObject instance?
While this is sometimes called integration testing (since you're testing the integration with the main application), it can also be considured unit testing in the classical sense as long as the test doesn't e.g. put data in a database or does anything else that could potentially influence other tests.
If the above isn't possible, you may resort to mocking out ThirdPartyObject e.g. using Mockito. Try to make sure you your test code isn't coupled to your implementation any more than it needs to be. Some people think they need to mock out all dependencies of a class and then verify all method calls to those dependencies. They're introducing a lot of strong coupling and redundancy.
Concerning the 2 problems you mentioned, there are ways around both:
1) You say you can't make ThirdPartyObject implement an interface. That's true, but you can write an adapter that implements this interface and delegates to a ThirdPartyObject. Then the method called by the main application would simply delegate to the actual plugin method implementation that uses this interface.
Example (suppose ThirdPartyObject has a single method void thirdPartyMethodCall():
public interface InterfaceForThirdPartyObject { void thirdPartyMethodCall(); } public class ThirdPartyObjectAdapter implements InterfaceForThirdPartyObject { private final ThirdPartyObject delegate; public ThirdPartyObjectAdapter(ThirdPartyObject delegate) { this.delegate = delegate; } public void thirdPartyMethodCall() { delegate.thirdPartyMethodCall(); } } // your actual plugin implementation, not directly exposed to the main app public class MyPlugin { public PerSpecResponseObject myPluginFunction(InterfaceForThirdPartyObject iUseThis){ // this will contain your actual logic that you want to test } } // this is the plugin as exposed to the main app public class MyPluginAdapter implements PluginInterface { private final MyPlugin delegate = new MyPlugin(); // this is called by the main application public PerSpecResponseObject myPluginFunction(ThirdPartyObject iUseThis) { delegate.myPluginFunction(new ThirdPartyObjectAdapter(iUseThis)); } }
2) You say you can't subclass ThirdPartyObject because the plugin implements an interface that has a ThirdPartyObject as method argument instead of ? extends ThirdPartyObject. I don't see why that would be a problem: a method that takes a ThirdPartyObject as parameter will happily take instances of any subclass of ThirdPartyObject.
