Unit Test Runners, AppDomains, and Testing Plug-In Code

Rhino Developer
, ,
10

@CallumSykes @sonderskovmathias

I think you’re thinking about this thread: add-userdata-object-reference-not-set-to-the-instance-of-an-object. I’ve been using what I posted there in my internal plugin for 2 years, it works great. I’m currently trying to add the capability to read the user data stored on a document into a block definition when you reference a whole document in, and so am going back through and writing tests for the existing behavior to make sure I don’t mess things up as I go forward.

I’m happy to talk about that implementation in a separate thread, let me know and I’ll create a pull request for the RhinoCommon example repo. I don’t want to get too far from the behavior that inspired this thread. Stepping back from UserData, you can observe the behavior with just this code inside of a test case. Assuming that you’ve loaded and registered your plugin, this code loads the plugin, but PlugIn.Find returns null, causing the last line to fail. At least for me, when running directly from the test explorers in either Visual Studio or Rider. If I run the test via NUnitLite as a standalone executable it succeeds. As far as I can tell this is because regardless of the AppDomain that Rhino.Inside is run from, it always creates the Rhino Process on the Default Application Domain.

[Test]
void LoadPluginTest()
{
    var plugin = PlugIn.Find(PluginConstants.RhinoPluginGuid);
    if (plugin is null)
    {
        if (PlugIn.LoadPlugIn(PluginConstants.RhinoPluginGuid))
        {
            plugin = PlugIn.Find(PluginConstants.RhinoPluginGuid);
        }
        else
        {
           Assert.Fail();
        }
    }
    Assert.That(plugin, Is.Not.Null);
}