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.