Testing the use cases of a frontend application

[nikoheikkila]

Hello, fellow community members! 👋🏼

Much talk and advice are offered when discussing how to test your front-end applications. Some people favour testing the UI by interacting with elements such as buttons. Others prefer to bypass the UI because it would make the tests slow and brittle.

I dwell somewhere in the middle and usually test the UI behaviour through interactions. When those are unavailable, I dispatch state-changing events (e.g. thunk actions in Redux) from my unit tests. Even with the latter, I prefer to verify that the UI has changed as expected, although I could verify that the correct actions were dispatched.

Especially regarding React applications, I tend to follow Kent C. Dodds' advice on writing tests for the application as close as a real user would use it. Of course, some developers disagree with the approach, but I haven't had any problems with it.

"The more your tests resemble the way your software is used, the more confidence they can give you."

Perhaps my question is, how do you design a clean architecture for a front-end application through TDD? First, I typically start writing tests for a dummy view component, which interacts with the backend through state actions. Then, finally, I break it into smaller stateless components in the refactoring phase of the TDD cycle.

[gregorriegler]

I like to start with a test that does a thing like the user would do it. So mostly blackbox, UI driven.
Then I make it pass as simple as possible.
Doing this I soon discover how I'm mixing UI Infrastructure code with UI Logic code. When that happens I use the existing tests to refactor and separate those two. This yields a seed of logic that is not UI but is nicely isolated and testable. Maybe its a countdown, or a calculator, or a data-retriever. I then test drive this new thing directly to cover the missing paths, forming a coherent model.
I end up with tests like the test-pyramid describes. A little through the UI, more on the unit level. My design has a boundary between the UI itself and the logic that is used by it.

[nikoheikkila]

This yields a seed of logic that is not UI but is nicely isolated and testable. Maybe its a countdown, or a calculator, or a data-retriever. I then test drive this new thing directly to cover the missing paths, forming a coherent model.
I end up with tests like the test-pyramid describes.

This is what I use as well. Often, my components contain logic unrelated to the component itself but can be extracted into a module or in a shared lib package. Easy to test, thus easy to reason about.