when releasing a new version of our plug-in, we test the new functions thoroughly. However, sometimes, some changes effect things, that have been previously working fine.
To systematically test “the old” functions and make sure we didn’t break anything, we had a long list of things to manually check.
But with the list is getting longer and longer and more time consuming.
So - I was wondering, how are others (you) approaching testing of your plug-ins?
Happy to get your input.
People call it “regression” and to avoid it unit tests can help.
Check out this: GitHub - tmakin/RhinoCommonUnitTesting: Example of unit testing RhinoCommon from within the Visual Studio test runner on windows
It’s much more difficult to automate the tests for UI in my opinion, but I believe there are some examples for e.g. WPF.
For Grasshopper plugins in particular what I’m doing is I create a test file where I have several testing definitions and with help of this plugin I check the outputs: Brontosaurus | Food4Rhino.
There are a few different approaches that you can often use when testing plug-ins, including:
- Regression testing: This involves testing previously working features to ensure that new changes have not introduced any unintended consequences or bugs. This can be done manually, but automated testing tools can also be used to speed up the process and reduce the chances of human error.
- Unit testing: Unit testing involves testing individual components or units of code to make sure that each one is functioning as expected. This can be useful for catching problems early in the development process, before they become more difficult to fix.
- User testing: User testing involves getting real users to test the plug-in and provide feedback on its functionality and user experience. This can help catch any issues that might not have been discovered through other forms of testing.
- Integration testing: Integration testing involves testing the interactions between different components of the plug-in to make sure that they are working together as expected. This can help catch any issues that might arise when different parts of the code come into contact with each other.
It’s often useful to use a combination of these approaches to get a comprehensive understanding of the state of your plug-in.