While writing tests for #2685, which adds an extra request for validating user permissions, several unrelated tests started failing.
It was found that the failure was due to the way these tests are doing assertions based on the axios mock history, now that there is a new request, the history has more than one item, and the validations are not passing.
There are about 34 test files that potentially have the issue, these do asserts like:
expect(axiosMock.history.post.length).toBe(1);
expect(axiosMock.history.post[0].data).toBe(...);
Now, because the useUserPermissions hook in #2685 is calling an extra endpoint, axiosMock.history.post.length becomes 2, and axiosMock.history.post[0] may be different than what the tests are expecting.
One possible approach for fixing this would be to wait for a specific history item with a specific url, instead of just accessing the first item in the history.
Example test that shows the issue here: https://github.com/WGU-Open-edX/frontend-app-authoring/blob/master/src/library-authoring/components/ComponentCard.test.tsx#L86
While writing tests for #2685, which adds an extra request for validating user permissions, several unrelated tests started failing.
It was found that the failure was due to the way these tests are doing assertions based on the axios mock history, now that there is a new request, the history has more than one item, and the validations are not passing.
There are about 34 test files that potentially have the issue, these do asserts like:
Now, because the useUserPermissions hook in #2685 is calling an extra endpoint,
axiosMock.history.post.lengthbecomes 2, andaxiosMock.history.post[0]may be different than what the tests are expecting.One possible approach for fixing this would be to wait for a specific history item with a specific url, instead of just accessing the first item in the history.
Example test that shows the issue here: https://github.com/WGU-Open-edX/frontend-app-authoring/blob/master/src/library-authoring/components/ComponentCard.test.tsx#L86