Kinda wish Josh would mention how he structures his tests in his projects. Something I'm currently struggling at work is that within our code repos, the pattern that everyone seems to copy is mimic the src/ directory for the test/ directory, rather than co-locating tests along with components. This means a structure for components: src/ components/ Button/ Button.tsx Is just copied ad-hoc for tests, so we get this: t…
That's exactly what Deno does [0] in its standard library. Colocate tests with code. It just works. Some people also like to go further the bad way and group code by type rather than feature. src/ components/ componentA.tsx componentB.tsx hooks/ hookA.ts hookB.ts tests/ componentA.test.tsx componentB.test.tsx Angular pre 1.5 liked this a lot. Must be a Java thing. https://deno.land/std@0.129.0/collections
Another one I despise is the page object pattern for E2E tests. Basically introducing a pseudo-DSL tied to something that is ever changing. I like the Cypress approach of using app actions instead:
https://www.cypress.io/blog/2019/01/03/stop-using-page-objec...
I utilize this in my playwright tests since I found it very useful when writing cypress tests previously.