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.
