Read on Twitter
I have some React + TDD thoughts:Most React devs don't practice TDD.
TDD purists believe call that heresy.
However, I'm leaning in the direction that not all frontend apps are worthy of unit tests.
Hear me out. I think (usually) E2E tests may only be necessary.
To prevent regressions, we chunk our application into "falsifiable units". TDD practitioners will write the failing test, then the code that makes it work.
On the server, with high-level policy- business rules and domain complexity, I find it hard to recommend NOT doing this.
On the server, with high-level policy- business rules and domain complexity, I find it hard to recommend NOT doing this.
However, I think most front-end developers are building dashboard applications. List & detail-view apps.
Fetch and display. https://twitter.com/dabit3/status/1331430689263251460?lang=en
Fetch and display. https://twitter.com/dabit3/status/1331430689263251460?lang=en
In these trivial cases, what's the best way to test these falsifiable units? Unit tests? No, I don't think so.
"Seeing" is innately human. And acceptance tests are customer (human) tests.
What better way than impersonate a human with an E2E test using Cypress?
"Seeing" is innately human. And acceptance tests are customer (human) tests.
What better way than impersonate a human with an E2E test using Cypress?
This is likely where 95% of us sit.
Things get more complicated when we need to test for correctness and it cannot be assumed by merely "looking".
Examples:
- Assuring an effects plugin works in an online digital audio workstation
- Multiplayer game logic
I've written about this before:
https://khalilstemmler.com/articles/client-side-architecture/architecture#div-classexpandable-sectionWhen-to-write-unit-testsdiv-classexpandable-section-button-onclicktoggleExpandableSectionunit-testsdivdiv
Examples:
- Assuring an effects plugin works in an online digital audio workstation
- Multiplayer game logic
I've written about this before:
https://khalilstemmler.com/articles/client-side-architecture/architecture#div-classexpandable-sectionWhen-to-write-unit-testsdiv-classexpandable-section-button-onclicktoggleExpandableSectionunit-testsdivdiv
In cases where there are several layers of interaction logic, I think we really need unit tests.
Though we should strive to keep as much high-level policy behind services (in the backend) and away from the web (an IO device).
But that's not possible in client-logic heavy apps.
Though we should strive to keep as much high-level policy behind services (in the backend) and away from the web (an IO device).
But that's not possible in client-logic heavy apps.
Summary:
- Most people aren't building client-side logic-heavy apps; most list and detail view apps, so I can understand why TDD isn't common practice on the web.
- Bet on E2E for list/detail-view apps.
- Bet on unit tests for apps with several layers of interaction logic.
- Most people aren't building client-side logic-heavy apps; most list and detail view apps, so I can understand why TDD isn't common practice on the web.
- Bet on E2E for list/detail-view apps.
- Bet on unit tests for apps with several layers of interaction logic.
