Hi there!
First, sorry to hear that the Reddit thread wasn’t helpful. I don’t spend much time on Reddit myself, but the Elm Slack organization is very active. If you’re interested in more real-time feedback, I’d suggest asking stuff in there.
You’re right that testing Cmds can be tricky, depending on what exactly you want to test. There are a couple options though:
-
Try to test your data before you turn it into a command. I like to think of the
Cmd as the final layer before I transfer control back to the Elm runtime. So I try to avoid testing Cmds directly; instead, I test the functions used in creating those values. If I have a function that like getFoo : Foo -> Cmd Msg, I might split that into two functions to make testing easier. The first would be getFooData : Foo -> FooData, which I would expose for testing, and the second would be sendFooData : FooData -> Cmd Msg, which would be very simple and untested. I’ve found a lot of success with this approach to splitting “logic” and effects.
-
Try elm-testable. This works for a subset of Elm
Cmds, and it requires you to change your imports. I’ve not used it myself, but it is recommended often in the #testing channel on Slack.
Hope one of these works out for you—or maybe others will chime in with different ideas!
