Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You're right, but testing the whole page's component functionality in large frontend apps isn't super common, either. In these cases, you would test the lower-level components and then not necessarily test their functionality for the whole page.

The costs of deep prop trees 1) kills many performance benefits offered by a good react/redux setup 2) makes it hard to build off of the state (much like a monolithic codebase) because it can be harder to find if something is already there or not.



I'm a non-React dev but I wrote modern apps with Angular (and have written React). I think the best testable approach really is:

1. unit testing on the smallest bits (Redux actions/reducers make unit testing them SUPER easy)

2. do e2e with something like Cypress.

Anything in between can be helpful but I found it can be too tedious, or difficult to do and ultimately, unit/e2e catches most things


I think this is a solid approach. I like to add snapshot testing for individual components too. The slowest tests to write for me are always the ones that involve some kind of async stuff.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: