Best practice:

- Use elm-doc-test for examples whereever possible, don't just write
documentation examples. They easily fall out of sync. If your
doc-tests start to look too crazy, it's possible your API could be
simplified.
- Have a test suite. Depending on your problem, your test suite may
need to be large and complex, in order to ensure all edge cases are
matched. If your package is mostly just glue code, there's not so much
need for that.
- If you have views, use elm-html-test. You can now also test events with this.
- If you are exposing something which is browser-dependant, e.g mouse,
touch, event decoders. You should have an integration test set up that
runs your code in a real browser

On Mon, May 8, 2017 at 4:38 PM, Eirik Sletteberg
<eiriksletteb...@gmail.com> wrote:
> Maybe write an example in the form of an integration test - then you know 
> your example will be up to date with the actual code, and it may even 
> discover bugs!
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to