If you modify and sometimes access not-threadsafe objects from another thread chances are high to break something. Even worse, sometimes it works, sometimes not.
I would always(!) invoke a change a RhinoObject within Rhinos Main Thread. I never encountered any issues with Rhino Objects, nor by adding, reading or modifing data within its thread. But I could be wrong.
Further more I don’t know if its helpful to test interaction with Rhino Objects in any of your Commands/Components.
If you wrap your interaction with RhinoObjects away from your codebase you can isolate this special case and test the rest totally isolated. You can even mock this RhinoObject-interaction then. This is what you usually do for untestable piece of code within an application.
Sometimes code is also written untestable. So if you like to test it, you maybe need to change the implementation as well, but I’m still not sure if invoking Unittesting within Rhino is the solution here.