Fork me on GitHub

Hi folks! I have a question about testing re-frame handlers that dispatch other handlers. I created a gist with my question that can be found here: Any help either here or as a comment in the gist would be greatly appreciated. Thanks!


Hi @alex.faber! I think there are two async behaviors happening here, and that's what makes testing a bit more complicated, but 100% possible: both dispatch and cljs.core/GET are async. Then I see two approaches for testing: 1. Keep the async behaviors during your test with the help of cljs.test/async and with-redefs to mock the get request (you don't want to hit the server, right?) but not mock dispatch. 2. Remove all the async behavior by mocking dispatch, you could still test everything in one test (by calling bad-response or process-response yourself, in your redef'ed dispatch)


With the second approach you can get closer to "unit tests". In the first one you are heading to "integration tests". I usually prefer the first approach, so I'm also more confident that everything is orchestrated correctly, but I know others prefer the second one


Yesterday someone answered a similar question involving om components doing an async request during will-mount, it might help you as an example of using cljs.test/async and with-redefs:


Thanks a bunch @nberger, this gives me something to look into for a bit. I’ve recently started to test my clojurescript code, so there’s much for me to learn it seems.


Np @alex.faber. Ask again in case of any doubt.


Anyone using re-frame with schema: (s/defschema DispatchVec [(s/one s/Keyword) (s/maybe s/Any)])


@hugobessaa: you bet. Saved me countless times and is a great way to remember the structure of your db.


using extensively now!


@hugobessaa: it's nice to schema-check your db after every update with some re-frame middleware in dev... not recommended in production though - it can seriously slow down your app (i use a goog-define var for dev/production)