feat: add integration tests for the enrollments api AP-1346

[BryanttV]

Description

This PR adds integration tests for the enrollment API. These tests are executed in the job of Tutor Integration Tests

This PR is part of a set of PRs to add integration tests to the enrollment API. It must be separated into different PRs because doing it in one PR exceeds the maximum size allowed by the pr-size-labeler action.

• test: add fake user data for testing purposes AP-1346 #281
• chore: remove old enrollments api integrations tests AP-1346 #282

Testing instructions

Check the jobs of Tutor Integration Tests in the PR.

Jira Issue

• AP-1346

[mariajgrimaldi]

I'll leave this so you can commit them in bulk.

[magajh]

@BryanttV can we please explain why is this implementation necessary in the PR description? I think it's important to explain the reasoning behind this decision

---

Since I’m considering moving tutor local do importdemocourse to the GitHub Action, should we also pass the course ID to the environment in the step that runs the integration tests? This way, the action would handle the full demo course setup, and we can ensure that the tests always reference the correct course and prevent each plugin from setting it manually

I was able to obtain the course ID dynamically with:

COURSE_KEY=$(tutor local exec lms python manage.py lms shell -c "from openedx.core.djangoapps.content.course_overviews.models import CourseOverview; course = CourseOverview.objects.first(); print(course.id, end='')")

However, if the import process changes in future Open edX versions, this could break the tests. Of course, we could always introduce version-based logic to handle that, but we could also just set the course ID manually in the action (assuming the Demo course ID won’t change frequently). Starting from Tutor version 18.0.0, the ID is course-v1:OpenedX+DemoX+DemoCourse, so we’d handle logic for both IDs for now, and remove support for versions below 18.0.0 later

I’d like to hear your thoughts on this approach @BryanttV @mariajgrimaldi

[BryanttV]

I really like what you propose. I think it's more appropriate to leave that responsibility to the action, than to keep it in every plugin.

[mariajgrimaldi]

We should definitely move this to the GH action itself.

I like the proposal's automatic approach to getting the course ID. However, I'm very wary of using code from the platform without any API or interface, even from the shell. I don't think it's worth it, considering the course ID hasn't changed much over time. The last change was very much needed: openedx/openedx-demo-course#50, it looks like it was very axim-specific for some reason.

[mariajgrimaldi]

I'll leave my approval again once we address the last couple of comments. Thank you!