You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Occasionally, the CI Check / frontend-tests fails because accessibility-spec.ts fails. For example a minor commit that changed a minor front-end component caused the following error. The previous commit passed all checks, and the new commit did not change anything related to the failing Cypress test. The GitHub action for this check is here.
AssertionError: Timed out retrying after 4000ms: Expected to find element: [data-cyId=requirements-showCompleted], but never found it.
After reviewing the video of the failed test, I believe that the assertion error results from the Cypress testing account not having any courses in its schedule. Other Cypress tests add courses to the schedule, so I assume that when those tests are run before the accessibility test, the accessibility test doesn't fail. I don't know how to determine the order in which tests are run, and I don't know when the Cypress account's semester data is reset.
This failure should happen more often if it's really caused by the tests being run in the wrong order. However, I reran the front-end test for a similar commit that unexpectedly failed for the same reason, and it passed the second time it was run. This is evidence that randomness is probably a factor! Run 1. Run 2. This is an issue that needs to be addressed, because a check should produce the same result every time it is run on the same commit.
There is no course in the plan so nothing shows in completed, which is why Cypress can't find that element to interact with.
I think we should add a course as part of this singular unit test so it doesn't rely on other ones.
A similar accessibility error occurred on beta-release after the release was merged in. This is problematic because a PR that passes all its checks before merging should also pass its checks after it's merged in. I don't think that that is related to this specific issue, but we still need to figure out why checks fail after passing previously. I think that check might have an issue with the release adding seasons.
The text was updated successfully, but these errors were encountered:
Occasionally, the CI Check / frontend-tests fails because accessibility-spec.ts fails. For example a minor commit that changed a minor front-end component caused the following error. The previous commit passed all checks, and the new commit did not change anything related to the failing Cypress test. The GitHub action for this check is here.
After reviewing the video of the failed test, I believe that the assertion error results from the Cypress testing account not having any courses in its schedule. Other Cypress tests add courses to the schedule, so I assume that when those tests are run before the accessibility test, the accessibility test doesn't fail. I don't know how to determine the order in which tests are run, and I don't know when the Cypress account's semester data is reset.
This failure should happen more often if it's really caused by the tests being run in the wrong order. However, I reran the front-end test for a similar commit that unexpectedly failed for the same reason, and it passed the second time it was run. This is evidence that randomness is probably a factor! Run 1. Run 2. This is an issue that needs to be addressed, because a check should produce the same result every time it is run on the same commit.
@willespencer:
A similar accessibility error occurred on beta-release after the release was merged in. This is problematic because a PR that passes all its checks before merging should also pass its checks after it's merged in. I don't think that that is related to this specific issue, but we still need to figure out why checks fail after passing previously. I think that check might have an issue with the release adding seasons.
The text was updated successfully, but these errors were encountered: