ISSUE-7711: Add GET - api/.../groups/test_results api route

[Naragod]

Proposed Changes

We wish to give users the ability to obtain test results through the API. This PR adds the following endpoint: GET - /api/courses/:course_id/assignments/:assignment_id/groups/:id/test_results.

Screenshots of your changes (if applicable)

Associated documentation repository pull request (if applicable)

Type of Change

(Write an X or a brief description next to the type or types that best describe your changes.)

Type	Applies?
🚨 Breaking change (fix or feature that would cause existing functionality to change)
✨ New feature (non-breaking change that adds functionality)	X
🐛 Bug fix (non-breaking change that fixes an issue)
🎨 User interface change (change to user interface; provide screenshots)
♻️ Refactoring (internal change to codebase, without changing functionality)
🚦 Test update (change that only adds or modifies tests)
📦 Dependency update (change that updates a dependency)
🔧 Internal (change that only affects developers or continuous integration)

Checklist

(Complete each of the following items for your pull request. Indicate that you have completed an item by changing the [ ] into a [x] in the raw text, or by clicking on the checkbox in the rendered description on GitHub.)

Before opening your pull request:

• I have performed a self-review of my changes.
  • Check that all changed files included in this pull request are intentional changes.
  • Check that all changes are relevant to the purpose of this pull request, as described above.
• I have added tests for my changes, if applicable.
  • This is required for all bug fixes and new features.
• I have updated the project documentation, if applicable.
  • This is required for new features.
• If this is my first contribution, I have added myself to the list of contributors.

After opening your pull request:

• I have updated the project Changelog (this is required for all changes).
• I have verified that the pre-commit.ci checks have passed.
• I have verified that the CI tests have passed.
• I have reviewed the test coverage changes reported by Coveralls.
• I have requested a review from a project maintainer.

Questions and Comments

This PR references:

• Wiki - Add GET - api/../groups/test_results endpoint documentation

[coveralls]

Pull Request Test Coverage Report for Build 20196133399

Details

• 96 of 96 (100.0%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.02%) to 91.53%

---

Totals
Change from base Build 20079147506:	0.02%
Covered Lines:	43748
Relevant Lines:	46990

---

💛 - Coveralls

[david-yz-liu]

This implementation does work, but I would like to see this align with the implementation of the JSON download through the UI, as I don't think it's good to have two different JSON formats exposed.

The existing JSON export makes use of Assignment#summary_test_results. You could add an optional parameter for a group id (or perhaps a list of group ids, which allows more possibilities in the future) to filter the existing query.

Note that the above method only returns the results for the latest test run. I think this is fine for now, since this is aligned with the existing JSON functionality. In the future we could extend this with an option to download all test runs.

[Naragod]

Hi David,

Would it be better to update the API call to follow the exiting JSON download structure, or should we update the existing implementation to download all test runs?

Here are the pros and cons of each:

UI format:

Pros:
 - Simpler
 - Grouped by group_name → test_group_name

New API Format:

Pros:
- Returns all test runs for the group
- Is structured as an array of test_runs with nested test_groups
- Includes metadata like test_run id, status, created_at

I have updated the new API implementation to use the existing the default UI implementation and added the option include_metadata to use the new API JSON format, which returns all test runs.

We can also update the exiting UI download implementation to provide all test runs and meta data.

[david-yz-liu]

Hi Mateo, for this PR I want to use exclusively what is already implemented and so please remove the other code from this PR.

If we decide to make changes in the future (to add all test runs) then I would like to do so by modifying the existing method and have it apply to both API and the UI exports. We would also have a discussion about exactly what the API parameters should be (I find the proposed include_metadata to be overly broad).

So please remove the code that you've added and just use the implementation in render_legacy_test_results (by the way, I also do not believe this is an appropriate name, as I do not consider the existing implementation to be "legacy").

[Naragod]

Sounds good. Please take another look.

[david-yz-liu]

Hi Mateo, for this PR I want to use exclusively what is already implemented and so please remove the other code from this PR.

If we decide to make changes in the future (to add all test runs) then I would like to do so by modifying the existing method and have it apply to both API and the UI exports. We would also have a discussion about exactly what the API parameters should be (I find the proposed include_metadata to be overly broad).

So please remove the code that you've added and just use the implementation in render_legacy_test_results (by the way, I also do not believe this is an appropriate name, as I do not consider the existing implementation to be "legacy").

[Naragod]

@david-yz-liu sounds good.

[david-yz-liu]

@Naragod oh yeah, I remembered that I had a similar conversation with one of my students a while ago, and some work in this direction is already present in #7599. This is a PR that I haven't yet had a chance to review but is on my radar.

[david-yz-liu]

It is better to filter within the Assignment#summary_test_results method itself to avoid loading a lot more test results. I think I saw an earlier comment about managing the nested queries in Assignment#summary_test_results; one suggestion is that you can add a where call immediately before Line 688 in assignment.rb.