Richard Feldman

> I know some people have had issues importing their main module for testing. It sounds like you'd have to do that to use this test, or otherwise move update...

I made a repo and pushed an (unpublished) draft to it: https://github.com/rtfeldman/test-update/blob/master/src/Test/Update.elm I did one thing differently: > The library code should (1) verify the initial model passes the test...

@Janiczek I got this to type-check (without shrinking) on https://github.com/elm-community/elm-test/pull/110 - want to try it out and see if it's useful in your case?

@JonathanFraser can you show us some code (or pseudocode) of what you'd like to be able to do?

cc @mgold @drathier @jwoudenberg @avh4 @Janiczek

@drathier since Travis jobs are repo-based, I think the way to do this "informationally" would be to create a separate repo which ran the real-world tests.

These are all great points! I tried comparing `--fuzz 20` and `--fuzz 100` on a pretty basic suite and the difference was negligible. Maybe the first step would be trying...

Gotta disagree - I think test performance optimization is very important. Slow test suites are big productivity costs on a big team, and there will never be a silver bullet...

> I'd like to propose attaching formatters to Expectations. These would default to toString for simplicity and backwards compatibility, but could be changed in less common cases like mine. I'd...

@rhofour - sorry, would you mind opening a new issue (in this repo) to discuss the implementation? I don't want that thread to get mixed with this one. 😅