Split test suite into unit/ and integration/ subdirectories

[jishanahmed-shaikh]

Describe your changes

Split the flat tests/ directory into tests/unit/ and tests/integration/ to make the distinction between fast isolated tests and slow S3-dependent tests visible in the file tree.

• tests/unit/: test_imports, test_config, test_cli, test_time_slicing, test_train_model_warnings, test_clamping (refactored to use DummyDatastore)
• tests/integration/: test_datastores, test_graph_creation, test_training, test_datasets, test_plotting, test_plot_graph
• conftest.py holds the S3 download fixture and init_datastore_example; conftest.py is stripped to shared env setup only
• test_clamping.py refactored to use DummyDatastore instead of MDPDatastore — no S3 dependency
• pyproject.toml: added [tool.pytest.ini_options] with testpaths and integration marker
• CI: split single pytest step into separate unit and integration runs

Issue Link

closes #599

Type of change

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

Checklist before requesting a review

• My branch is up-to-date with the target branch
• I have performed a self-review of my code
• For any new/modified functions/classes I have added docstrings that clearly describe its purpose, expected inputs and returned values
• I have placed in-line comments to clarify the intent of any hard-to-understand passages of my code
• I have updated the README to cover introduced code changes
• I have added tests that prove my fix is effective or that my feature works
• I have given the PR a name that clearly describes the change, written in imperative form
• I have requested a reviewer and an assignee

Checklist for reviewers

• the code is readable
• the code is well tested
• the code is documented (including return types and parameters)
• the code is easy to maintain

Author checklist after completed review

• I have added a line to the CHANGELOG describing this change, in a section reflecting type of change (maintenance)

[sadamov]

Thanks @jishanahmed-shaikh, direction is right. A few things to address before merge.

Top-level:

• uv.lock (+5079 lines) is unrelated to the test split, please remove and open a separate PR if committing the lockfile is desired.
• Delete tests/unit/conftest.py entirely. ensure_rank_zero and WANDB_MODE are already in the root tests/conftest.py and pytest picks up parent conftests automatically.
• --tb=short is passed to the unit run but not the integration run, please align.
• Branch is CONFLICTING with main, needs a rebase.

Inline comments below.

[sadamov]

Hi @jishanahmed-shaikh, are you still interested in driving this one? It would need a rebase, the inline comments above addressed, and the ~7 new test files added to tests/ since (e.g. test_custom_loggers.py, test_utils.py, test_probabilistic_objectives.py) classified as unit vs integration.

I'd also want to discuss the unit/integration split as a convention at a dev meeting before enforcing it, so even with a rebase ready the PR might sit a bit. Let me know if you still have bandwidth, otherwise happy to close until someone picks it up. Thanks for the proposal either way!

[jishanahmed-shaikh]

Hi @jishanahmed-shaikh, are you still interested in driving this one? It would need a rebase, the inline comments above addressed, and the ~7 new test files added to tests/ since (e.g. test_custom_loggers.py, test_utils.py, test_probabilistic_objectives.py) classified as unit vs integration.

I'd also want to discuss the unit/integration split as a convention at a dev meeting before enforcing it, so even with a rebase ready the PR might sit a bit. Let me know if you still have bandwidth, otherwise happy to close until someone picks it up. Thanks for the proposal either way!

Hi, thanks for checking in.

I'm still interested in working on this, but due to other commitments I wouldn't be able to dedicate the necessary bandwidth for another 2 weeks. Realistically, I'd want enough time to properly rebase, address the review comments, and go through the newer test files and classification work.

If that timeline works for the project, I'd be happy to pick it back up then. Otherwise, I completely understand if you'd prefer to close the PR for now and have someone else take it on.

Thanks again for reaching out, and I appreciate the flexibility either way.