[#11826] Add unit tests for SubmitFeedbackResponsesAction

[undermyumbrella1]

Fixes #11826
Questions:

1. SubmitFeedbackResponsesAction has dependencies on several other classses. Should these dependencies by stubbed? From similar unit tests of other components, dependencies are not subbed.
2. In SubmitFeedbackResponseAction:execute(), if FeedbackResponseDetails is null, an AssertionError is thrown. May I clarify that this behaviour does not need to be tested? (as it is an expected behaviour)
3. Not sure if I understood the type of questions that a Feedback Response can be issued for, is correctly used.

[zhaojj2209]

Thank you for your PR! To answer your questions:

1. No need to stub them, current approach is alright. However, do note that as part of our ongoing database migration project, our test code will undergo an overhaul as well, so dependencies may be mocked in the future. We will aim to have your PR resolved before then so that you won't have to make too many changes to your PR.
2. Yes, no need to test this.
3. Looks alright to me.

Some slight adjustments on my end. Personally I would also say that some private helper functions are not very necessary, but it's not a big issue.

[zhaojj2209]

LGTM!

No worries regarding what I mentioned previously about the abstraction of private helper functions. Whether a piece of code is over-abstracted is rather subjective, which is why I did not request for further changes.

For your own learning, though, the SWE @ Google chapter on unit testing explains DRY in testing pretty well, so it's worth a read!

[samuelfangjw]

Great work on this!

We will merge this into main, but do note that we are currently working on an overhaul of the backend, including the tests. These test classes will be removed or migrated in the month or so.

SubmitFeedbackResponsesAction has dependencies on several other classses. Should these dependencies by stubbed? From similar unit tests of other components, dependencies are not subbed.

Unit Tests here is really a misnomer. These really should be called integration tests instead. We are looking to change this in the near future with a more traditional mix of unit and integration tests. Feel free to have a look if you are interested, though note that the tests on this branch require a few more rounds of polishing before I would consider them ready to be merged.