[Tracker] Add Unit Tests for Core Components

[eprikazchikov]

📌 Description

This issue focuses on improving the test coverage and reliability of Thunder Engine by adding unit tests for key classes and functions in the codebase. Many core components currently lack dedicated unit tests, which are essential for preventing regressions and ensuring code correctness as the project evolves.

Your task is to write clean, focused Google Test (GTest) unit tests for specific, relatively isolated parts of the engine (like math utilities, data structures, or simple component logic). This is a foundational contribution that will make the engine more robust for everyone.

🎯 Why This is a Good First Issue

• Clear Scope: You will be working on well-defined, smaller functions or classes, not complex systems.
• Direct Impact: Every test you write adds a layer of quality assurance and protects against future bugs.
• Learn the Codebase: Writing tests is an excellent way to understand how different parts of the engine work and are intended to be used.
• Guided Process: Suggested starting points and examples are provided below.

🔍 What Needs to Be Done

We need to increase unit test coverage in several areas. Good initial targets are pure functions and classes with clear input/output that are currently under-tested. For example:

• Atlas
• Engine
• Transform
• PiplineContext
• PiplineTask
• ResourceSystem

📚 Example: Writing a GTest

Check file engine/tests/tst_actor.h for example

🚀 Steps to Contribute

1. Set Up:
   • Fork the repository and clone it locally.
   • Ensure you can build the project and run the existing tests. Refer to the main README.md and tests/ directory for instructions.
2. Explore & Choose:
   • Browse the engine/ or modules/ directories to find a suitable, simple class or namespace to test. Good candidates are files with little to no corresponding test file currently.
   • Look at the tests/ directory structure to understand where new tests should go.
3. Write Tests:
   • Create a new tst_%classname%.h file in the appropriate tests/ subdirectory (or add to an existing one). One file for each class. Each module can contain a separate tests/ directory.
   • Follow the GTest style shown in existing tests and in the example above.
   • Focus on key behaviors: constructors, important methods, operators, and edge cases.
   • Use TEST() for isolated tests or TEST_F() for a tests which requires some initial state.
4. Verify:
   • Build the test suite.
   • Run your new tests locally to ensure they pass.
5. Submit:
   • Create a Pull Request with a title like: "Tests: Add coverage for PiplineContext class".
   • Left this ticket #1223 as a reference in your PR to simplify tracking of your PR
   • Briefly describe what functionality your new tests cover.

🆘 How to Get Help

• If you're unsure about the expected behavior of a function, ask in a comment on this issue.
• Consult the Google Test Primer for fundamentals.
• The project's CONTRIBUTING.md guide has general instructions for contributors.

💡 Notes for Contributors

• Start Simple: Begin with a single class or a small set of related functions.
• Test Behavior, Not Implementation: Focus on what the function should do (its contract), not how it does it internally.
• Cover Basics First: Tests for constructors, getters, setters, and core logic are most valuable initially.
• Edge Cases Matter: Consider testing with zero values, negative values, or near limits if applicable.

[Shree1194]

"Hi @eprikazchikov! Improving test coverage is a great way to ensure engine stability. I'm interested in helping with unit tests for the Transform or PipelineContext classes.
I noticed you mentioned tst_actor.h as a reference. Should I create separate headers for each new test file following the tst_%classname%.h pattern in the tests/ directory? Also, do you have a preference between using TEST() or TEST_F() fixtures for these core components? Looking forward to contributing!"

[eprikazchikov]

Hi @Shree1194

Should I create separate headers for each new test file following the tst_%classname%.h pattern in the tests/ directory?

Yes these files must be be created for each class. One class -> one test suite (one file).

Also, do you have a preference between using TEST() or TEST_F() fixtures for these core components?

It depends on specific test. If u have isolated test you should use TEST() if you need to prepare objects configuration you should use TEST_F()

Description will be updated accordingly your questions.

[Shree1194]

Thanks for the clarification @eprikazchikov! I'll pick the Transform class to start with as it's a core component. I'll follow the tst_transform.h naming convention and use TEST_F() to handle the coordinate setups. I'll submit a PR once I've verified the local build. Please tag me if there are any specific edge cases you want covered for Transform!