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
headershas aContent-Typeofapplication/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.