Alpine: Model binding tests for all input types

[muzafferdede]

As lesson learned from #401 i think we should include all input types in tests for model bindings.

<input type="button">
<input type="checkbox">
<input type="color">
<input type="date">
<input type="datetime-local">
<input type="email">
<input type="file">
<input type="hidden">
<input type="image">
<input type="month">
<input type="number">
<input type="password">
<input type="radio">
<input type="range">
<input type="reset">
<input type="search">
<input type="submit">
<input type="tel">
<input type="text">
<input type="time">
<input type="url">
<input type="week">

It will improve future feature tests. Not sure what tests would do the job other than simple foo - bar bindings. Suggestions on binding scenarios?

[ryangjchandler]

As I mentioned in #401, I actually tihnk the general test coverage for input elements and others is pretty good. There are a few inconsistencies here and there, but these make more sense to tackle as they come up or become a problem, for example Safari and the selection range stuff.

[muzafferdede]

@ryangjchandler
Whether or not it's sneaky, all edge cases should be tested really. At least we know now going forwards.

@ryangjchandler
We (me, @HugoDF, @SimoTod) do try and comment on PRs to ensure they're fully tested, this one just slipped past a little since there are inconsistencies between input types / elements. Definitely a good thing to remember going forward, research the solution too :)

After reading your comments there, I was thinking it might help to prevent just slipped past a little :) You are free the close the issue if you don't see the necessary of it.

[HugoDF]

It will improve future feature tests. Not sure what tests would do the job other than simple foo - bar bindings. Suggestions on binding scenarios?

There's probably a point of diminishing returns we need to be weary of. At the end of the day, currently all tests are run inside of JSDom which isn't a 1-1 with browsers.

If we really want to be on the safe side, E2E tests using something like Cypress (except it doesn't have IE11 or Safari support) would be the most useful to catch browser quirks before releasing code.

But this project has limited resource and I don't know if anyone is keen on spending that time writing tests.

After reading your comments there, I was thinking it might help to prevent just slipped past a little :) You are free the close the issue if you don't see the necessary of it.

Testing won't be 100% regardless of what approach we take that's the nature of it, projects much bigger than this one have inadvertently introduced breaking changes in a patch version in the past.

Unfortunately, for the foreseeable future, time to remediation will be bound to Caleb's time/attention.

[HugoDF]

So having spoken with Caleb, Ryan and Simone yesterday

This is something that would be useful as a sanity check, if someone wants to contribute the tests cc @muzafferdede

[muzafferdede]

Good to know @HugoDF. If it's going to be like foo & bar type of tests, better to leave it to new contributors as starting point.
Reference livewire

[HugoDF]

Cool let's leave it for now and someone can pick it up if there's no movement for a while

[rantomanik]

[hristiy4n]

Correct me if I am wrong, but I looked at the tests for model binding and it seems like the following input types are already covered:

<input type="number">
<input type="radio">
<input type="checkbox">
<input type="text">

With "simple foo - bar bindings", do you mean testing the behaviour of the input element with a simple model bind? (ex. binding anything else than a 7-character string specifying an RGB color in hexadecimal format to <input type="color"> would default to #000000)