Add automated unit tests for ray intersection and collision functions

[222448082Ashen]

Description

Added automated unit tests for ray intersection functions, migrating interactive tests from test_geometry.cpp to proper unit tests that can run in CI/CD pipelines.

Changes:

• Added unit tests for rectangle_ray_intersection in unit_test_geometry.cpp
• Added unit tests for circle_ray_intersection in unit_test_geometry.cpp
• Added unit tests for triangle_ray_intersection in unit_test_geometry.cpp
• Added unit tests for quad_ray_intersection in unit_test_geometry.cpp
• Added unit tests for bitmap_ray_collision in unit_test_bitmap.cpp
• Added test for detecting closest intersection among multiple shapes
• Added necessary includes for geometry headers and physics

Motivation:
The ray intersection functionality previously only had interactive visual tests that required manual inspection. These new automated tests enable continuous integration testing and prevent regressions.

Fixes # (issue)

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation (update or new)

How Has This Been Tested?

Test Details:

• All tests are automated using Catch2 framework
• Tests validate both boolean return values and output parameters (hit points, distances)
• Edge cases tested: rays pointing away, parallel rays, rays from inside shapes
• Multiple shape priority testing validates distance-based collision detection

To reproduce:

# From MSYS2 MinGW64 terminal
cd projects/cmake
cmake -G "Unix Makefiles" .
make
cd ../../bin

# Run all unit tests
./skunit_tests

# Run only ray intersection tests
./skunit_tests "[ray_intersection]"
./skunit_tests "[ray_collision]"

Testing Checklist

• Tested with sktest (not applicable - these are unit tests)
• Tested with skunit_tests (syntax validated, ready for build/test)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have requested a review from ... on the Pull Request

[rory-cd]

General Information

Type of Change:

• New unit tests

This PR provides well-structured unit tests translated from the geometry integration test, using sections to avoid duplicating code and cleanly separating test scenarios. While some changes are required to ensure tests are robust, this will make a solid foundation for testing ray intersection and collision functions.

Requested changes are marked inline, along with some optional improvements.

Code Quality

• Repository: The Pull Request is made to the correct repository
• Readability: The code is generally easy to read and follow, with useful comments provided
• Maintainability: This code could easily be maintained or extended in the future

Functionality

• Correctness: While the code nicely translates much of the integration test into unit testing format, one of the tests fails, and some of the tests cannot fail.
• Impact on Existing Functionality: The impact on existing functionality been considered

Testing

• Test Results: Ran skunit_tests. One test failed, due to lines 1070 and 1071 of unit_test_geometry.cpp. Details in inline comments.

Pull Request Details

• PR Description: The problem being solved is clearly described
• Checklist Completion: All relevant checklist items have been reviewed and completed

[rory-cd]

Optional improvement: To check whether the rays should be intersecting these bitmaps, the image sizes must be checked. Consider creating bitmaps and drawing shapes onto them manually, as this would make the sizes explicit, and reduce room for error.

If the resources are kept, consider adding null checks here (e.g. REQUIRE(bmp_1 != nullptr);). This would give consistency with the other tests in this file, and make any errors more specific (for example, when a bitmap is not null, but is not valid).

[rory-cd]

Issue:

This section seems to be meant for testing ray collisions with multiple bitmaps simultaneously. At the moment, this is three separate rays testing three separate bitmaps, and the test only fails if one of these rays doesn't intersect.

Suggested fix:

• To avoid transparency issues, bitmaps should be created/drawn rather than loaded.
• The ray should intersect all three bitmaps simultaneously
• The assertion should be REQUIRE((collision_1 && collision_2 && collision_3))

[rory-cd]

Issue:

This assertion always passes, and therefore isn't improving the test case.

Suggested fix:

• Change to REQUIRE(collision_below); and ensure the bitmap dimensions are static.
• The section only tests rays from different locations (rather than edge cases or different functionality), and may be better off as part of the "can detect ray collision with bitmap" section. This would also fit with how you approached "can perform rectangle ray intersection" in unit_test_geometry.cpp.

[rory-cd]

Issue:

This is a good case to test, but again the assertions always pass.

Suggested fix:

Make assertions more specific, e.g. REQUIRE(collision_cell_0);

Optional improvement:

Test bitmaps with multiple cells (e.g. A case where cell 1 should have a collision but cell 2 shoudn't)

[rory-cd]

The use of __DBL_MIN__ here doesn't seem necessary unless the test relates to near-zero values. Since the purpose of the test is to check missed rays, could this be rectangle_ray_intersection(point_at(95.0, 95.0), vector_to(1.0, 0.0), r1) instead?

[rory-cd]

Optional improvement: This test was already done in the previous test case. Instead, consider covering the case where the ray starts from inside the rectangle (as noted in the function documentation)

[rory-cd]

Issue:

These lines were causing the test to fail, due to incorrect values. According to the API Docs, hit_point.x should be 300, and distance should be 0.

Suggested fix:

Change to:

REQUIRE(hit_point.x == 300.0);
REQUIRE(distance == 0);

[rory-cd]

Issue:

• Line 1106 is too vague to test correctness - This is understandable, since the triangle is quite skewed, so the distance is difficult to calculate exactly. But at the moment, this is saying "as long as the hit point is detected after the ray origin, that's a success"
• Line 1108 is also too vague - as per above

Suggested fix:

• Provide a more specific equality assertion, or an upper bound
• Use an axis-aligned, equilateral triangle to make calculations/assertions simpler

[rory-cd]

Issue:

• Line 1143 assertion is too vague - As per the triangle test, this is understandable, since the quad is skewed, but at the moment this assertion doesn't test correctness.
• Line 1144 assertion is too vague - as per above
• Assertion for hit_point.y is missing

Suggested fix:

• Provide more specific equality assertions, or upper bounds
• Use an axis-aligned quad to make calculations/assertions simpler
• Add assertion for hit_point.y

[rory-cd]

This test case reflects the integration test, but as a unit test it doesn't pertain to a particular SplashKit function, and doubles up on some functionality already tested. We know from previous tests that each of these functions returns an accurate value, so nothing new is being tested. The implementation is effective but I would suggest removing it from the unit tests.