I wanted to share an update regarding the enhancement of our O3 integration tests. Recently, we have discovered that we can improve the O3 integration tests by utilizing MockServiceWorker (MSW), a tool specifically designed for mocking API calls. Currently, I am in the process of configuring MockServiceWorker on the esm-admin-tools repository.
When we execute tests with MockServiceWorker, it intercepts the API calls specified in the handlers and replaces them with the predefined responses. Following the MSW documentation, I have configured it on the esm-admin-tools repository by implementing a sample handler through this pull request. For debugging purposes, I have enabled the option to list all unhandled request intercepts.
Unfortunately, I have encountered a problem with the implementation: it appears that none of the API requests are being intercepted.
I also had a discussion regarding this with @dkigen on the last dev standup call and the problem might be related to the openmrsFetch function. I’ll be further looking into fixing this issue. Any guidance or suggestions would be greatly appreciated. Thank you.
We provide a mocks for calls to the framework in jest tests, including a mock for openmrsFetch, so there are no requests for the service worker to intercept.
Did you run into some issue that lead you to want to use this library? Is there some short-coming with our current approach?
Thank you for your response. The reason I explored using MockServiceWorker (MSW) was not due to any shortcomings in our current approach, but rather to explore potential advantages that MSW offers. I came across an article which highlighted the benefits of using MSW for mocking API calls.
With MSW, we can achieve advantages such as easier usage, reducing duplication of mock setup across tests, and having simpler and cleaner code. It provides a declarative way to define handlers and predefined responses, making it more intuitive and efficient to simulate API behavior.
I see. That makes some sense. However, from the article:
This will give you a bit more confidence that a request is actually being issued, but another thing that this test is lacking is an assertion that the headers has a Content-Type of application/json. Without that, how can you be certain that the server is going to recognize that request you’re making? Oh, and how do you ensure that the correct authentication information is being sent along as well?
This is largely a non-concern for most of our tests. The rationale for having openmrsFetch() and openmrsObservableFetch() is basically that they handle all of those concerns (and we can build unit tests for that).
However, let’s zoom out a little bit more: our testing strategy has been focused on e2e tests largely so we can avoid having to mock things altogether. We use unit tests primarily for bits of code which implement complex, application-specific logic, which is—generally speaking—mostly just stuff in core. The idea being that we want to do the bulk of our testing without having to mock anything, i.e., making real API calls to a real backend and ensuring that components render as expected. This allows us to largely avoid having to think about how to mock the backend, how to keep those mocks in sync with changes to the backend, APIs, etc. In other words, this is pushing the project in a direction that, I think, is questionable at best.
Project-history-wise, there was a time when we were developing frontend modules by mocking backend calls completely. This was great for developer velocity, but it lead us to a condition where we had several “implemented” MFs that would never work in production because they relied on APIs that either didn’t exist or didn’t return data in the expected format. I’d worry that returning to testing using largely mocked APIs would actually result in returning to code that works for demos, but not for actual use.