This is not, strictly speaking, a Ladybug Tools question - so apologies in advance for that. But I wonder if I might ask for some advice, if anyone has any, on the best protocol for writing unittests for my own Python code? In particular, given the large amount of awesome .py code the LBT team has built, I wonder if you have some thoughts on a particular issues I am getting stuck on?
I’m trying to do a better job of testing my code, currently using pytest for most projects - that all works great and I like it a lot. BUT, when I am working on code that I will be using inside the Rhino/GH environment, I’m at a loss for how to manage the Rhino-side dependencies properly? For instance, if I have same super simple code that I’ll later import into some GH components, I can write and test it just fine on its own, so long as it doesn’t have dependencies:
BUT, if I want to do something like use a Rhino or Grasshopper class or function for some reason, now my test-discovery and test-execution fails cus’, obviously, it doesn’t know how to resolve the ‘import Rhino’ line:
The actual code all works fine of course, once its imported into GH and run there
so its not a functional problem - but I’m not sure how to properly set things up so I can test it better? Is this a spot where I should be trying to use mock or patch (still learning all that jazz)? Should I be passing the Rhino module as a dependency to my class during initialization in a case like this? Should I be creating an interface to handle all the Rhino, scriptcontext, etc… items I’d like my classes to be able to access?
I’m sure there isn’t a single answer, but I wonder: given the amount of Python you’ve all written, how are you managing the tests in a scenario like this? I notice that you seem to have nicely segregated most all of your RH dependent code into the ladybug_rhino module, which seems great? Do you think I should I be trying to isolate all my Rhino-entangled code into a separate module and just… not… test it? Any thoughts or advice are of course appreciated, as always.
thanks for any thoughts! best,
@edpmay