Thanks Mark for this fantastic and very detailed answer.
I never thought about applying regression to a UI state and I definitely
want to mull about the idea further.
My gut feeling tells me that manually informing the shrinker wether it's a
good or bad state is gonna be too much work but hey, git bisect works that
way and it's great so who knows.
To be honest my needs are met by the functions in the Random module. I
wasn't aware you could easily create generators for custom types, so I
should just have done my research better, but it was worth asking here as I
left with a few great ideas to explore.
Thanks again!
On Tuesday, December 6, 2016 at 3:27:45 PM UTC, Max Goldstein wrote:
>
> I see now. You want to see a UI widget in many possible states for the
> purposes of seeing a visual regression. (By "widget", I mean some piece of
> HTML generated by a function, not the loaded word "component", which
> usually implies state. Although it could be either.) Without saying too
> much, I know there is some programmatic HTML-based testing in the pipeline
> but actually seeing the rendered output would be a nice complement to that.
>
> If all you want to do is generate a random value of the Model type, you
> should be fine with Random, not fuzzers. All of the map functions for
> fuzzers have versions in the core Random library, and I'd be happy to go
> into more detail here if you need it.
>
> The other possibility is to randomly generate many Msg values, and run
> update on them. This has the potential benefit of testing the update
> function, and avoiding some weird mode state that update would never
> produce (though as much as possible such states should be made
> unrepresentable).
>
> But back to fuzzers: a fuzzer is just a random number generator plus a way
> to shrink the value generated. There *might* be value in shrinking those UI
> widget examples. Imagine devcards, except when you see a visual regression,
> you can hit a button to generate a model that is in some way "smaller" than
> the previous one. You can keep doing this (and rejecting changes that "fix"
> the problem) until you get to a minimal reproduction of the error. This
> would likely give insight into the root cause, and ideally, the example can
> be saved as a regression test.
>
> This has an impact on how I was planning to expose fuzzers. I think for
> this use case, you'd want to take a fuzzer and say, "give me a random
> value, and a way to say that it does or does not reproduce an error." It
> would also have an impact on how view functions are written. It's common to
> write
>
> viewHelper : Model -> Html Msg
>
> indicating that the function consumes the entire model, which could be a
> very large record. If you wrote instead
>
> viewHelper : { a | name : String }
>
> this indicates that any record with a name field of type string is
> acceptable. It will accept a larger record, such as model, but also just
> {name : "Steve"}. This means shrinking can target the fields the view is
> using, and not the ones it is ignoring, to produce a much better result. It
> also means that you'd need to produce a special fuzzer for this function,
> and expose it from its module (typically the View module hides its helpers).
>
> So, I might be getting ahead of myself here. If it's worthwhile to be able
> to shrink models that cause visual glitches, than this is a road we can
> pursue further. If not, and even if it is but in the short term, I think
> you will be able to randomly generate a model with the random libraries,
> not fuzzers.
>
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
