test: add tests for MarksGradersController#randomly_assign method

[danielrafailov1]

Proposed Changes

Implemented full test coverage for the randomly_assign method of the MarksGradersController class as per assigned task. Specifically, I took inspiration from the tests related to the unassign_all method to implement 5 seperate tests.

The first test ensures two things. Firstly that the randomly_assign_tas function gets called with the correct parameters (specifically two non-empty arrays of students and graders), and secondly that when all of the correct parameters are included in the body of the POST request, we get an ok response (200) response returned.

The second test ensures two things. Firstly that when we pass in an empty array of students to the request body we get a bad request returned. Secondly, we flash the user to indicate that they need to select a student.

The third test is the same as the second with the graders array being empty instead of the students array and the flash message being tailored to this.

The fourth test is the same as the second test with the only difference being that the students array is entirely omitted from the request body instead of just being empty.

The fifth test is the same as the third test with the only difference being that the graders array is entirely omitted from the request body instead of just being empty.

The sixth test is similar to the first test. It ensures that when all of the correct parameters are included in the body of the POST request, we get an ok response (200) response returned. However it differs from the first test in two ways. Firstly, we no longer mock the call to the randomly_assign_tas method. This is done so that we can actually ensure that the method did what it was supposed to do. Secondly, we ensure that the method did what it was supposed to do in the sense that every student should be assigned exactly one TA.

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)
🐛 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)	X
📦 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

(Include any questions or comments you have regarding your changes.)

Should I add another test to verify the order and number of students?

[coveralls]

Coverage Report for CI Build 26204813023

Coverage increased (+0.03%) to 90.242%

Details

• Coverage increased (+0.03%) from the base build.
• Patch coverage: 45 of 45 lines across 2 files are fully covered (100%).
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	49716
Covered Lines:	45835
Line Coverage:	92.19%
Relevant Branches:	2151
Covered Branches:	971
Branch Coverage:	45.14%
Branches in Coverage %:	Yes
Coverage Strength:	128.08 hits per line

---

💛 - Coveralls

[david-yz-liu]

Nice work @danielrafailov1. I left a few comments, and also:

1. Your PR is missing information in the template under "Proposed Changes". This is a key section in which you should describe what the purpose of the PR is and the changes it contains.
2. In response to your question, yes I think it would be good to add another test to verify the behaviour when there are multiple students and graders specified.

[david-yz-liu]

Add this entry under "Internal Changes", as we reserve the "New features and improvements" section for user-facing changes.

[david-yz-liu]

This code and the above line can be simplified, as we provide a factory for grade entry students directly. This means that you can use create(:grade_entry_student), you just need to also specify the associated grade_entry_form

[david-yz-liu]

I think you may have missed that this comment was also referring specifically to Line 388. On GitHub, comments appear directly underneath the specific line that was selected when making the comment.