Training-loop-level unit tests are difficult to write because training behavior depends heavily on global state.
For example:
- The test discussed in PR #7112 had to parse and mutate global arguments, reset global variables and the microbatch calculator, and repeatedly initialize and destroy model-parallel state.
test_mcore_adapter.py manually resets several CUDA graph wrappers and static buffers to prevent state from leaking between tests.
It would be useful to have shared test utilities that initialize, isolate, and clean up this state, making short training-loop tests easier to write and understand.
The current alternative is a functional test. However, functional tests depend on golden values, which introduce maintenance and comparison challenges. They also expose only predefined metrics, making it difficult to inspect intermediate values or assert directly on internal training behavior.
Tag @NVIDIA/mcore-oncall. I talked about this during the standup. I don't think anyone is ready to work on this, but I'm still filing it to keep the record.
Training-loop-level unit tests are difficult to write because training behavior depends heavily on global state.
For example:
test_mcore_adapter.pymanually resets several CUDA graph wrappers and static buffers to prevent state from leaking between tests.It would be useful to have shared test utilities that initialize, isolate, and clean up this state, making short training-loop tests easier to write and understand.
The current alternative is a functional test. However, functional tests depend on golden values, which introduce maintenance and comparison challenges. They also expose only predefined metrics, making it difficult to inspect intermediate values or assert directly on internal training behavior.
Tag @NVIDIA/mcore-oncall. I talked about this during the standup. I don't think anyone is ready to work on this, but I'm still filing it to keep the record.