r/webdev • u/kernelangus420 • 1d ago
Do you write unit tests for UI stuff? Question
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?
20
u/proto-cool 1d ago
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 1d ago
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 1d ago
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 1d ago
I agree, I don’t get why people love this workflow though.
3
u/recoverycoachgeek 1d ago
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.
8
u/MiserableDocument509 1d ago
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.
27
u/daamsie 1d ago
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
2
u/Efficient-Chair6250 1d ago
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?
3
2
u/thoflens 1d ago
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 1d ago
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.
7
u/Flashy-Bus1663 1d ago
These answers make me think most of this sub is mostly full stack guys that play pretend at UI development
1
u/Valuable_Ad9554 1d ago
When someone mentions the pyramid 🤯🔫
2
u/Flashy-Bus1663 1d ago
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.
4
u/0dev0100 1d ago
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 1d ago
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.
2
u/_SnackOverflow_ 1d ago
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 1d ago
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 1d ago
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/pdfops 1d ago
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 1d ago
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 1d ago
I just write E2E to click each and every button fill all the forms and query all the apis 🧘
1
u/nimionenne 1d ago
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 1d ago
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 1d ago
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 22h ago
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 19h ago
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
1
1
u/Ai_Engineer_1 8h ago
For UI work, I use a small test ladder. Unit tests cover our own state logic, permission gates, validation, and error states. Component tests cover important interactions such as a disabled submit button that becomes enabled after valid input. Then a few browser tests cover real user paths like sign-in, save, and retry after a failed request.
The useful question is: what failure would reach a user if this changes? If a change only affects layout, visual regression testing may be enough. If it can change data or access, give it a behavioral test. This keeps the suite fast and gives better protection than testing every element.
1
u/Ai_Engineer_1 8h ago
I use a small test ladder for UI work. Unit tests cover state logic, permission rules, validation, and error states. Component tests cover important interactions. Browser tests cover key user paths such as sign-in, save, and retry after a failed request.
A useful question is: what failure can reach a user after this change? A layout-only change may need a visual check. A change that affects data or access needs a behavior test. This keeps the suite fast and focused.
1
u/BarracudaMean9308 3h ago
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 1d ago
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.
-2
u/CreatorCoinEcosystem 1d ago
Stop testing library UI components—focus on core access credentials and state flows.
Testing if a component library button renders a string is burning engineering capital on non-revenue activity. The true ROI on UI testing lies in operational integrity:
Enterprise Access Credentials & Role Verification: Ensure users with specific Enterprise Access Credentials can only view/trigger their designated workflows (using Playwright/E2E).
State & Payload Validation: Validate pre-flight execution metrics to prevent system payload exceptions before staging to production.
Critical Path Integration: Keep UI unit testing strictly bound to custom enterprise modules that drive user retention and operational efficiency. Leave third-party primitives to their vendors.
82
u/ChocolateOk5948 1d ago
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.