When a project becomes a hydra you have to know how to trim its heads (GCollision Unit Test Phase)

Writing a library for Gateware can be a task that may seem vast and steep. Previously, I had discussed the monstrous interface I created for the Gateware GCollision library and now I will discuss the challenge with it going into the next stage of creating this library which is: dummy unit tests. The GCollision currently has about 1950 functions, but a lot of them are the same functionality overloaded. I imagine about a fifth of that or less are somewhat unique functions. It's a bit hard to tell at the moment because even then it's quite overwhelming, but no matter how trivial some of these maybe they still require unit tests. With each unit test possibly requiring multiple positive and negative tests, you're now looking at a hydra of a project. So, where do we go from here?

I shared my update with the lead software architect, Lari, and he was easily able to suggest the solution to ensure this library will be complete within time. Prioritize completing the unit tests and functions that will most likely be the most used by the users. I know it seems obvious, but I had researched this for a month prior to this step and every function and geometrical representation that I chose had become one of my babies. I didn't want to abandon any of them. Lari had less attachment to them and his suggestion is more realistic. I'm also more healthier now that I can work on batches of the library instead of spending who knows how many man-hours writing unit tests before I even get a function going. Below is a table of the first priority batch which is the test if two objects are touching or not from the shapes: point to OBB.