The Practical Framework Guide

• Think about classes/IDs you can use as markers when writing tests to ensure content is rendered properly. Generally speaking, the performance impact of a small helper class to verify markup is nil; and if it does become a problem you can refactor the markup later.

test HTML as minimally & focused as possible

This means 2 things:

• if there’s a layer before the view layer where you can test something, test it there.
• If you are testing for some specific markup, it should be as focused as possible

Testing before the view layer

Trying to test something at the view layer usually is a symptom of not having confidence in the individual systems that make up your app, and their interplay.

If you’re testing for a particular error message, or that a particular state is rendered from the server, that could be a sign that:

• you aren’t sure the major cases are covered
• That your app doesn’t properly fail in a way you can systemically notice
• You actually want tests at the view component level, rather than the view itself

There are legitimate exceptions to this, more on that at the end

ViewComponents are annoying to unit test, with diminishing returns

This one is slightly controversial; but I find ViewComponents annoying to write tests for, and the results of said tests end up with diminished returns. However, their setup is great when you need those tests. The design of singular instance state, (ideally) simple data structures, and

focused, specific markup

If you are trying to write tests at the view layer, make sure to keep them focused on specific markup that acts as an indicator & spot check. The reality is that trying to comprehensively assert the completeness and wholistic nature of your view is very onerous & a waste of testing effort. That time would be better spent designing systems are are more easily composable, debuggable. And writing tests at the lower level.