Unit test for RhinoObject

Rhino Developer
,
1

Hi All,

Not sure if anyone has figured out how to do unit tests for RhinoObject.
One of main reason that I want to do this is because I want to keep tracking of RhinoObject ID, and now I have to test it manually in Rhino App.

It’d be much appreciated if anyone could provide any insight.

cc @dale
Best,
Mingbo

2

@Alain - is this something you can help with?

3

Hello,

I don’t understand exactly what you want to test.

We’re using NUnit internally. We load a custom test runner in a plug-in so the tests can run in the context or Rhino.

An easier option is probably to launch EditPythonScript and use Python’s unit testing framework, unittest.

Does that work for you?

4

Thanks @Alain and @dale,

I am also using NUnit as well.
So here is what I am working on:

  1. save RhinoObject’s ID in a customized UserData, along with other metadata.
  2. add this UserData to RhinoObject’s Geometry.
  3. by doing so, I can validate this userdata , when RhinoObject is duplicated and userData hasn’t been updated.

For other GeometryBase’s test, I am following this setup, and this works great. GitHub - tmakin/RhinoCommonUnitTesting: Example of unit testing RhinoCommon from within the Visual Studio test runner on windows

Here is an example of my unit test, and of course this doesn’t work.
RhinoDoc.Open returns null.

image
image1274×430 26.7 KB

Is it possible to provide a sample for this workflow?

Thanks in advance.
Mingbo

1 Like
5

Hi @Alain,
Some quick example of your NUnit workflow would also be really welcome :slight_smile:
Thanks in advance!

6

Our NUnit workflow is not a polished process, is not automated, and covers a only subset of our code base. Test fixtures are in assemblies and a plug-in command launches a runner (provided by @curtisw) from which you can load and run your tests.

7

@dale @Alain @jeffoulet

Finally got something working, I will share after I clean it up.
Theoretically this can also be used for testing Grasshopper components.

RhinoUnitTest
RhinoUnitTest1285×777 225 KB

5 Likes
8

Here is an example demo:

9

Looks nice,

it still seems like you are doing integration testing with a unit test framework. I think you don‘t need to test if creating or retreiving information from a RhinoObject works since this part of your software is not of your domain. You can expect it to work properly. Only testing your own code base in a very singular manner is a unit test. And this should be feasible within Visual Studio directly.

10

Thanks, yes, I have a part of unit tests related to geometry are tested within Visual Studio directly. But I also have parts like parallel processing geometry with UserData attached. It has to be tested in Rhino, and I wouldn’t find out this crashes Rhino every time if I didn’t test it in Rhino. This is just simply that Rhino doc is monitoring each UserData across the entire document, and it cannot be accessed/duplicated by multiple threads.

These two weeks, I have been experiencing 3 Rhino bugs already (one of which has been reported by other 4 years ago, but still hasn’t been fixed), and I cannot expect Rhino will work with UserData properly without testing.

Rhino has been giving me a lot of surprises lately.

This is my ultimate goal to have all my code tested without opening Rhino.

11

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.

12

Thanks for your advice, this is very helpful.

I think the main part of reason that I have to test some of unit tests within Rhino is because the Geometry’s UserData can only be accessed when Rhino doc exists (@dale please correct me, I might be wrong, but this is what I am experiencing).

The main part of my code is dealing with geometry’s UserData. Not directly testing on RhinoObject, but RhinoObject is an indication of Rhino doc’s presence.