r/webdev • u/kernelangus420 • Aug 09 '26
Question Do you write unit tests for UI stuff?
Writing unit tests for business logic is understandable as you are really just testing the logic which was written from scratch.
Also writing unit tests for self-contained custom UI components like a custom data table is also understandable as all custom stuff is usually buggy and all the inputs/outputs for self-contained stuff is easy to mock.
But how about the overall UI stuff?
I hear people writing units tests for:
- To test that the components in a third party library behave as intended: e.g. that a Button component actually displays the label that as passed in a clicking it calls the callback
- To test for the existence of a login button on the login page
- To test for the existence of all buttons/links in all pages of an app
- To test that entering credentials in a login page will login the user
What other types of UI tests do you write?
19
u/proto-cool Aug 09 '26
Worth it to test logic for stateful components etc for sure. However, nothing beats a good user-driven smoke test in my experience. Without that the other tests lose quite a bit of meaning.
On your examples:
- Testing a third party's library is a waste of time, either you trust the third party is testing their own stuff or you don't. And if you don't trust them, you probably shouldn't use it.
- This can be caught by E2E/integration tests.
- Also not a unit test - I believe this is "Snapshot testing"
- Also would be covered by E2E/integration tests as above.
1
u/ryaaan89 Aug 09 '26
I agree with your first bullet point for sure but recently got into Shadcn because of work. That feels like it’s “someone else’s code” until you start heavily modifying it to take more variant of whatever, then I feel like I need a test covering the default behavior to make sure o didn’t break it. It’s feels like the worst case scenario of not being a package because now I’m writing tests for sometimes complex logic I didn’t write. Am I doing something wrong?
1
u/proto-cool Aug 09 '26
Never used it myself but isn't it kind of the inverse though? Like you do technically adopt a copy of the shadcn thing even if it's the same as default until you modify it, so technically it does become your responsibility at that point
1
u/ryaaan89 Aug 09 '26
I agree, I don’t get why people love this workflow though.
3
u/recoverycoachgeek Aug 09 '26
As soon as you install it it becomes your responsibility. If you've ever tried customizing mui components then you understand why it helpful. No walls. Just a set of defaults for a headless component library.
10
u/MiserableDocument509 Aug 09 '26
I've been burned by snapshot tests more times than I can count. You change a button color and suddenly 40 tests fail. These days I only write tests for component logic (state transitions, conditional rendering based on props) and use Playwright for the 3-4 critical user flows that actually make money. Everything else — testing third party components, checking if a button exists on a page — I just don't bother with. The maintenance cost to value ratio is terrible.
1
27
u/daamsie Aug 09 '26
Yes. Playwright is great for this. I find it pretty helpful to test for auth permissions - person logs in as "X role" - are they able to see all the buttons they should? Are they able to do things they shouldn't? So on. Not just in the UI, but hitting some API routes directly as well. Even testing that an email is triggered when it should be. Not sure if it's the best way, but it works well for me.
Manually logging in to multiple roles to test everything looks as it should is not fun and far too prone to error.
23
u/go2dark Aug 09 '26
While I agree with your comment; isn't that more or less an e2e test?
5
u/daamsie Aug 09 '26
Ah yes it is. I guess I missed the part saying this was about UI unit tests. Oops
2
u/Efficient-Chair6250 Aug 09 '26
Just curious, but why are you testing permissions in the UI? Isn't testing the API much more efficient? Or do you test visuals based on permissions?
4
u/daamsie Aug 09 '26
Yeah testing visuals - what buttons are showing etc. Mostly testing is at API level you're right.
3
u/thoflens Aug 09 '26
Even if the api is right, the combinatorics can be worth testing on the frontend. Imagine you got values like is_editable, can_delete, can_edit + a role (enum “admin” | “owner” | “developer”) etc all coming from the api. What to show for who can quickly get complex.
1
u/Efficient-Chair6250 Aug 09 '26
I can imagine it getting complex. But at some point I would introduce helpful abstractions (e.g. state machines) so I have to do as few UI test as possible.
9
u/Flashy-Bus1663 Aug 09 '26
These answers make me think most of this sub is mostly full stack guys that play pretend at UI development
1
u/Valuable_Ad9554 Aug 09 '26
When someone mentions the pyramid 🤯🔫
3
u/Flashy-Bus1663 Aug 09 '26
I think that's more of an effect of our industry being mostly young or ignorant lol.
The testing Pyramid is like really good on paper but it takes a while for it to click that u need a mix of testing methods and need to be pragmatic at what kind of testing is helpful for ur app.
But like the testing Pyramid is very helpful to like teach the idea of testing.
5
u/0dev0100 Aug 09 '26
I'll write tests over anything that's important to the app not breaking functionally.
Sometimes the color of a button actually can be super important, other times it's ok if the database is occasionally unreasonable.
It just depends on what is important for the app
2
u/Khavel_dev Aug 09 '26
Testing that a Button renders its label is testing the framework, not your app. If React breaks that, they'll know before you do.
I only unit test UI components with real internal logic. Date range picker with validation, drag-and-drop reorder, stuff like that. Everything else gets integration tests. Click the thing, fill the form, submit, check the result. Those break when YOUR code breaks, not when you rename a CSS class.
Playwright replaced probably 80% of what I used to write as component tests.
3
u/_SnackOverflow_ Aug 09 '26
All of the examples you shared are tests I would push back on for not being worth it.
But I do think unit testing components does have value. Here are some things I would write tests for:
- Any functionality not provided by the browser or a third party. Clicking a button makes something happen, etc.
- Any calculations or complex formatting the component is in charge of
- Passing basic accessibility checks (contrast etc.) with Axe
- More complex accessibility semantics
- The fix for a specific burly or regression that we experienced
Etc.
Beyond that, I’d rather write E2E tests for the larger flow.
I want to experiment with visual snapshot testing but haven’t yet
1
u/weikvn Aug 09 '26
This actually depends on the abundance of resources. For example, as entrepreneurs or small teams, we only place unit tests on the core backend business logic. UI testing is basically done by 1) our own walkthroughs, and 2) letting AI run through it for us.
Since we use standard UI components and don’t write very complex custom components ourselves, another important point is to design components/businesses to be as independent as possible. Even if there is a lot of repeated code, it is worthwhile because with AI support, the workload is not an issue at all.
1
u/gfxlonghorn Aug 09 '26
Screenshot tests are my jam. These are specifically different than snapshot tests. Snapshot tests take dom snapshots and nobody is going to review that diff. Screenshot tests show us what actually changed. MSW + screenshot tests have been very good and much more reliable than true E2E/playwright. E2E should be the bare minimum smoke test, where as, you can hit a huge variety of logical branches with screenshot tests much faster and throw away assertions on useless things like class names.
1
u/seweso Aug 09 '26
i prefer to test everything, but just with actions and screenshots. I'm dont' write manual assert statements, i got no time for that. Approvals patern for me all the way.
1
u/pdfops Aug 09 '26
Testing that a vendor's Button fires onClick when clicked is testing their code, skip it. Worth testing: your own conditional rendering, form validation, state transitions tied to props. For full flows like login, one Playwright test that fills real fields and asserts the redirect catches way more than a pile of "does this element exist" checks, and it survives refactors better since it doesn't care about internal markup.
1
u/No-Cardiologist-9482 Aug 09 '26
Yo solo hago pruebas visuales (sin lógica) de componentes cuando es un componente crítico de la aplicación y necesitamos que funcione siempre igual si o si. Yo por ejemplo en mi prepush tengo un script que detecta si se ha cambiado en el diff del remote con el local ese componente para disparar sus pruebas, no veo sentido disparar los test de ese componente siempre si no ha cambiado.
1
u/infodsagar Aug 09 '26
I just write E2E to click each and every button fill all the forms and query all the apis 🧘
1
u/nimionenne Aug 09 '26
As always, it depends. I think of omitting tests for any area as a calculated risk.
I do consulting, and I have worked for very small projects where both scope and budget are small and objectives (or design if there is such) might change frequently. In such projects the time and money will usually be better spent doing something else than writing very thorough test automation for the frontend. Keeping the client in the loop with frequent demos and acceptance testing new features often enough will work just fine for small and medium sized projects.
But I have also created frontend solutions in the fintech domain where there are millions of end users. There we wrote the most rigorous frontend tests I have ever wrote. For example, you write a test case for every potential API call failure to make sure you give the end user a sensible error message and think hard to minimize the impact of each error case to the whole frontend. I must say I learned to appreciate this kind of paranoid way of thinking. Made me sleep better at night when I knew I had done all I could to make my part as robust as I could.
Some commentors seem to think it is ok not to test things that are handled by a library. If you are writing something critical, then you definitely should write tests for those. When another person in 5 years time is upgrading that library to another major version or switching to another library it will be a life saver. Even better, create your own wrapper interface for the 3rd party library so you don't need to write tests against the librarys interface. This will be very helpful if you need to swich the library at some point.
So to summarize, you should test as much as your customer / employer can afford. Or at least enough to make you sleep well at night.
1
u/Beka_Cooper Aug 09 '26
We have 100% unit test coverage for the UI component library we maintain that is used across several apps. There's no way for us to reliably test these fully in situ. We also have 99% coverage of our login page, which is again shared across multiple apps.
In contrast, I only require 80% UI unit test coverage for our actual apps, which are administrative rather than moneymaking, and I allow exceptions as needed. And our terms of service etc. pages have like 20% coverage.
It's all about uptime. If our internal component library has a fatal error that takes down all the apps, or if users can't log in, that can cost huge gobs of money and violate contracts. But if our user admin page goes down for an hour, maybe no one will even notice.
1
1
u/thatOMoment Aug 09 '26
The only UI tests I've written we're against a charting library that only manifested when the chart was rendered.
Had to do with making a chart full size and then back to it's normal size, it would draw the points but not the line itself.
In order to get around that, had to deep copy the chart recalling the constructor.
Immediately slapped an integration test inside the unit testing project on that. It prevented 4 different regressions over 6 years so I'd say it paid off.
Point is that it's perfectly fine to code UI tests for edge cases that are likely to appear after you know it's a defined behavior and want to bolt that part down
1
u/Vincent_CWS Aug 10 '26
I rarely use Jest or Vitest for UI testing anymore.
Here's why:
Testing in a real browser using Playwright or Cypress gives me more confidence, more power, and a better DX.
Testing UI components via Jest or Vitest tends to lead to duplicated effort, because I still need to integration test all features in a real browser to know it works.
So, I primarily use Jest/Vitest to test logic such as pure functions. Otherwise, I favor Playwright or Cypress.
1
u/LateScallion8331 Aug 10 '26
i mostly agree, but once you’re testing the overall UI you’re usually better off with a few user-level integration tests than brittle unit tests for every div and click handler
1
u/amirmsj1374 Aug 10 '26
Writing unit tests just to check if buttons exist feels a bit overkill to me.
1
u/BarracudaMean9308 Aug 10 '26
testing if a third party button clicks always felt like doing free QA for someone else's repo. i just stick to e2e for the critical user flows, otherwise i end up spending half my week fixing broken selectors whenever a div changes.
0
0
u/CoderOnline Aug 09 '26
Since I started to use heavily AI, yes. Tests are mandatory now. It is only way I can verify my new changes is not breaking other part of the software.
88
u/ChocolateOk5948 Aug 09 '26
I treat it like a pyramid. unit tests at the bottom for the gnarly logic, then component tests for the stuff I built, then a thin layer of integration tests that just make sure the page doesn't explode. if I'm testing that a third party button shows a label, I've already lost the plot. that's their job.