How do you test a TEA `update` function?

[Francesco Orsenigo]

How do you write unit tests to ensure that an `update : Msg -> Model -> ( Model, Cmd Msg )` function is producing the correct commands?
What if the function is supposed to produce several commands batched together?

Same thing for a `view : Model -> Html Msg`.
Suppose I want to test whether, given a particular model, it will display the correct number of list items.
Do people write tests for this?
Right now the only way to write this kind of tests I can think of is creating the whole html tree as I expect it to be rendered, and comparing it via == with the function output.

[Simon]

I've often worried about the commands bit.

For the view side, you need to test that you are deriving the right data to render, while it is Evan that needs to test that, given certain data, expected DOM elements get produced?

[Austin Bingham]

I asked more or less the same question about a month ago and got no responses:

    https://www.reddit.com/r/elm/comments/593vua/how_to_test_the_complete_update_cycle/

    https://groups.google.com/d/msg/elm-discuss/634UXiZjRFQ/lVeDED1oBQAJ

The only practical answer right now seems to be to use elm-testable, though I haven't actually tried it myself.

This feels like a real blind-spot in the elm ecosystem. The generation and handling of Cmds is central to a properly functioning app, but there doesn't seem to be any first-class way to test e.g. Update without driving the entire app from the top-level. 

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Simon]

... which is ironic given all emphasis on 'effects as data'....

[Oliver Searle-Barnes]

This is an area I've been a little uncomfortable with. There seems two be a couple of options though:

1) https://github.com/avh4/elm-testable - I haven't used it but it seems that it provides replacement commands that you can run assertions against. This approach seems limited as it only solves the problem for a predefined set of commands.

2) Another approach, which I also haven't tried yet: Instead of returning commands from your update, model the effects yourself and only convert them into commands at the last minute when returning them from your main/update. For instance you might return MyEffects.request(endpoint, verb, payload, GoodResponse, BadResponse). This would allow you to just use assertEquals on the effects returned from your update. Something that would need to be taken care of though is a replacement for Cmd.map. 

[Mark Hamburg]

See, for example, here:

https://groups.google.com/forum/#!topic/elm-discuss/qhLsLThplUo

An approach in which one waits "longer" to convert requests to commands appears to be more readily testable. (That said, I haven't taken to writing unit tests yet for this code and while one can compare for equality, command like entities will tend to involve tagger functions which may result in fatal runtime errors in those equality checks.)

Mark

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscribe@googlegroups.com.

[Francesco Orsenigo]

Ok, but is it justified to make your code more complicated just to enable testing?

[Mark Hamburg]

We didn't do it to enable testing. We did it because it also regularizes a lot of other module interactions. Improving testing is a bonus.

Mark

On Nov 8, 2016, at 1:31 PM, Francesco Orsenigo <francesco...@gmail.com> wrote:

Ok, but is it justified to make your code more complicated just to enable testing?

--

[Francesco Orsenigo]

Fair enough!

> You received this message because you are subscribed to a topic in the

> Google Groups "Elm Discuss" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/IYp-bI93AnY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to