2

Somehow mocking xhr requests (?) for Axios is really hard to make it work. I use React Cosmos as I'm re-doing the frontend of this already running in production and works great, but when my component communicates with the backend it breaks and I'm unable to test the full behavior.

Then, it occurred to me that trying to mock Axios may not be the best. So I came with this scheme where I would have a configuration variable with a default value and change that when I need to work with React Cosmos, which in turn changes the behavior of `/auth` to return a valid JWT in response to a GET, put an Axios interceptor in my outermost Cosmos decorator and BAM! suddenly was able to develop and test my React components closer to how they would work in production.

It surprises me how simple this endeavor was, and because everything runs orchestrated by docker compose things run smoother.

(this is not an excuse to not to learn how to deal with the mocking issues of Axios, after all I wont have a working backend every time I work in some frontend application)

Comments
  • 2
    Use jest?
  • 1
    @devTea should I? I'm designing components not only implementing business logic
  • 1
    @catholic-emacs I don’t get it, you don’t implement any logic or you only implement the logic? Anyway jest can test both the UI and js only
  • 1
    @devTea implementing both, but in my experience asking Jest to interact with the UI can become cumbersome (specially if you are a newbie with like I am). I can manually interact with what I'm working with React Cosmos, which helps do fast iterations.
  • 0
    Jest will be use eventually, after finishing iterating all components, to ensure what I saw during development does not change as side effect of some other change.
Add Comment