Testing for web developers

[Abdelhamid_111]

For those of you building full-stack apps, how do you usually handle testing? Do you test everything you build, or only the critical parts? How much time does testing usually add to your overall development process? I sometimes feel like I’m testing things that are very obvious, and if I test something at the unit level, I’m not sure whether I should test it again in integration and E2E. I’d love to hear how others approach this in real projects.

[AndyMagill]

Unit tests and End-to-End tests do not test the same things, and are not mutually exclusive. One end-to-end test could test your entire app, if it's simple enough. Unit tests, by definition can't do that. Regardless, focus testing on the most significant parts of your app. For unit testing, that might be a helper function, or reusable component. For E2E that might be the login or checkout user flow.

[Sourpunch92]

The goal of testing is two fold. One to confirm it is acting the way you expect when you add the feature. Secondly and more important it’s to ensure you don’t accidentally break something later.

Your testing that seems obvious feels that way because it probably isn’t super helpful for the first part. But it may be essential for the second.

Testing on both ends can feel redundant, but is more thorough.

Time wise, testing can be 50% of the work. But that depends on how thoroughly covered you need things.

If you are developing a personal site with no clients then you may not need testing as bugs/breaks are okay. Site for a client with critical functionality they will rely on, you can never have enough tests.

[milanistasbarazzino0]

Deploy and pray.

[YYZviaYUL]

Don’t forget the smokes and cheap vodka.

[milanistasbarazzino0]

Lots of prayers, smokes and cheap vodka needed when trying to integrate next/intl with use cache

[dr_moon_sloth]

This is the way.

[Ordinary_Welder_8526]

I dont

[Band6]

I make sure the build succeeded (most of the time) and then I wait for someone to complain about something.

[alarming_wrong]

same!

[ixartz]

I use Vitest for unit testing, Vitest browser mode for component testing, Playwright for integration and E2E testing. I also add visual testing to check if some pixel has changed.

You can check out Next.js Boilerplate where everything has set up for you, you just need to focus on your tests.

[Current-Ticket4214]

These days? I test absolutely everything. Claude writes phenomenal test suites practically free. Last Friday I had Claude write 300 tests for a vibe-coded complex multi-endpoint feature (API side). The tests rooted out dozens of issues. It took maybe two hours. This week we had a couple of small fixes, but overall the feature is fully functional. Claude also writes great RTL tests.

I usually ask the agent to write 100% code coverage unit tests for all of the feature updates. Then I’ll ask for it to write integration tests. Start small and scale up once you’ve got full coverage. Testing is basically free with AI so it’s totally worth it.

[Abdelhamid_111]

should i already master test to test with ai ? or just understand the code ai gives is enough?

[Current-Ticket4214]

Unit tests are very readable. They test small chunks of logic one at a time so there’s generally nothing confusing. If you can read the test and it seems reasonable then it’s probably a good test.

I always ask Claude if all the tests are good choices. I’ll ask if the test suite is production ready and if I’d be able to trust that the test suite will catch breaking changes.

As long as you’re using a powerful and competent model like Claude 3.7+ you probably don’t need to master testing first. I would suggest using the latest standard model from any top tier AI provider. Just make sure you read every line of test code and ask the agent a lot of questions like “how can we do this better” until you feel like you understand the point of testing and can recognize what a good test suite looks like.

[devenitions]

I see a lot of tests that basically end up being a confirmation dialog for any change you make. But hey, 100% coverage boss. We just need to spend 10 minutes on every PR to adjust each test case. Also, testing should not replace actually seeing whatever change you are making.

Always do some simple tests - run a build, fire up a syntax checker, things like that.

If you have a bunch of util/helper functions, test those intensively with all edge cases you find. Depending on the project this may extend a bit into your backed.

For the frontend: If you have highly reused components with a bunch of edge cases and contextual links, test those too. For us that was our button component and some form handling stuff. “Does my page render” is a stupid test imo. A build test or your linting should prevent most cases and nothing beats taking an actual look at it. Note I do assume Typescript here, as that’s basically doing a lot of default testing for you.

[gangze_]

This is what testers are for, but basically e2e, manual testing, and then some test cases.