This topic describes a need for a new kind of component, a component for capturing requirements in a grasshopper definition.
A requirement can be useful to formalize an agreement between stakeholders (designer, end-user, manufacturer, …). In my experience, a requirement is a sentence that is understandable by all and that can be verified. The set of requirement is a reminder of what the design shall satisfy.
In the example below, some requirements about an egg cup are written in a panel component (left panel).
The proposal for a “requirement” component is to have a way to write the requirement (as in a panel component) and link it to the set of design components that provide the verification of the requirement. In the above case, it would be a “link” to the eggcup and the egg that are seen on the right panel.
In my opinion, the link could be similar to the link between a galapagos component and the slider component. The “requirement” component could have a “display verification” button that provides a selected preview of the objects that prove that the requirement is met.
I was thinking of these as ‘tests’. Have the ability to create your own gh files which act on some data and either do nothing or generate a violation message. You can then associate these gh files with specific parameters in another file to see if they pass the test.
Tests would be very flexible this way so could easily verify volume, area, bounding box limitations, list lengths, or anything else you can measure using standard components.
I believe this (now) to be a non-negotiable part of a professional coding environment.
Good idea, “Test” file would be a nice feature. In software development for instance, we develop test file to automaticaly verify that requirements are met. This is something we do at the end of a project (even if it is a best practice to write your test before you code).
The idea here is somewhat different. It is to have the requirement elicited in grasshopper at the beginning of the project. We could later link those requirements to the “test” file you mention.
Naughty naughty. Tests first, code second, such are the edicts of TDD.
I must admit that I’m having trouble always starting with the test code, I just try to develop both simultaneously.
I haven’t given a huge deal of thought about how the interface for tests would work, I’ve sketched out some ideas over my Christmas holiday but it’s all subject to change. Still, the basic mechanism seems reasonably obvious provided one stays within the GH interface paradigm. Boxes-and-wires, all the way down.
At the moment I’m using some custom test classes, a unit test project, and two custom GH components to do this.
The GH components de/serialize input/outputs of the GH definitions used for testing.
The custom classes are there to make the process more user friendly.
It’s fidlly but it works
Hi Lorenzogreco and David Rutten,
I still believe TDD and Unit Testing is one of the critical features for any programming language. I am hoping if I can get advice from people who do TDD in Grasshopper. I found topics somewhat related to this topic such as Managing Large Projects and Version control - Grasshopper . However none of them quite allowed the TDD experience and debugging process. I understand that people might say Visual Programming is different. However that does not mean it can be filled with bugs and issues. How do you verify that your program isn’t filled with bugs without test file?
So I gave a shot with the advice and tips above. Serialize and Deserialize combined with cluster such that clusters can be exported with reference so that it can be updated quite easily.
(The reason I want to do TDD in Grasshopper environement and not Python or C# in Grasshopper is because I want to use thid party library and component.)
If anyone can give me an advice on how to do TDD in Grasshopper properly then that will be extremely helpful.
I’m cleaning up my Unit Test set up, I will share it at some point today hopefully
there you go:
Awesome! Thank you for sharing it.
I will test it out and provide you the feedback.
Sorry for the late reply.
This works great! Thank you so much for sharing this.
I will try to find a way that makes TDD and version control process in Grasshopper most convenient and practical and report you back if you don’t mind.
I still need to grasp the concept behind TCP/IP connection.
hello tadashi, what were your findings?