Component tests poc

[jdmarshall]

I'd like to make contributions to the core_components set and I suspect others might want to do the same, rather than jumping immediately to their own or third party replacements.

Given that there are for instance missing input types, and a few bugs still being found in the existing components, I think it would be good if there were some pinning tests, and a pattern to add more tests, so that new features or bug fixes are less likely to introduce regressions in existing functionality.

This also might be a good way to make sure that --no-tailwind or other --no flags don't create a bunch of issues.

This is basically a placeholder test because I know testing but my knowledge of phoenix LV is still a bit spotty.

It was suggested (Chris?) that these should be integration tests and I think I understand why.

[josevalim]

Thank you @jdmarshall, what you have in mind here? It feels most of the bugs are UI related, so how could that help? We already compile this code, so those errors would be caught too.

[jdmarshall]

I'd like to specifically catch regressions in any PRs meant to enhance the templates, and any components that accompany the templates.

There's currently no part of the lifecycle that tests that and the generated tests also don't have much code coverage here, leaving consumers to write their own functional tests, which only tells them they have breaking changes in phoenix to deal with instead of preventing those changes from happening without transparency to begin with. And that's also a route to a Testing Cone instead of a Test Pyramid.

And I think in particular in the case of the inputs, circa 1.17, the lack of feature parity between some of the components would be much more obvious in the face of covering unit tests.

[josevalim]

I understand that in theory but I am wondering which kind of unit tests would be written in practice. :) we do have integration tests though through the general scaffold stuff

[jdmarshall]

Where are the integration tests for the core components? I injected bugs into the code and still got green builds.

And furthermore I see PRs for the core components code with no tests included.

[josevalim]

We test the phx.gen.live generators, so we test they are functional. But for things like changes to style and classes, there is nothing we could really test. We could test a certain component has a certain class but that does not really buy us anything, as the class may not exist or be the wrong class or look visually ugly. Which is why I am asking which tests would be written. If there are no examples for now, then it is best to close until we have some practical ones!

[SteffenDE]

I was thinking it would be more practical to just add playwright tests for what we do in the generator integration tests. Those could actually make screenshots and assert visually on those.

[jdmarshall]

I was thinking more of the reading and expansion of the parameters into DOM, though typos in style concatenation are not impossible either. The table component was quite complex. Select and lists aren’t exactly trivial. Nor would be checkbox or radio groups.