Ask HN: How to view UI changes before & after a pull request?

[seestraw]

I've been a backend developer for a while. My team has been sending me frontend PRs lately. I find it hard to see visual changes before and after a PR request. This is for UI changes, not for logic changes. Is there any tool that can make this smoother?

[lelandfe]

I've heard this called "snapshot testing"

I've used Chromatic before and really enjoyed it: https://www.chromatic.com/features/test

Jest also offers the core functionality if you want to roll your own tests: https://jestjs.io/docs/snapshot-testing

[advanderveer]

I can second the effectiveness of Chromatic, essential for us at crewlinker.com. We have over 80 components with 281 stories, all being checked for visual regressions on every PR. It is also surprisingly effective of just catching regular errors that occur because some rendering logic may indeed result in the app crashing.

[octatrack]

I also vouch for Chromatic, it has been extremely valuable for us. It is only working with Storybook, though, as it's made by the same company.

[2rsf]

I suppose any decent visual testing tool would work, there are quite a few of them

[seestraw]

Thanks! Is Chromatic only for Storybook?

[lelandfe]

It's tightly integrated with it, so if not "only for Storybook," then near to it. I like Storybook, but it's not worth implementing solely for visual CI testing IMO.

But phrases like "snapshot testing" and "visual regression testing" are what you you/your FE team should be Googling – hopefully there's a tool out there that fits your existing architecture!

Otherwise, as sibling commenters have noted, a policy of screenshots also works.

[efortis]

I upload a before and after picture or a video to the ticket, and then link it in the PR description, so design or product can comment before developers.

[hboon]

Yes, for UI changes, we upload before and after screenshots too.

[curthipster]

I think you're asking about automating the screenshot comparison, and there are some answers about that already. I wanted to chime in with a complementary comment.

We recently started using Vercel to host our front-end application, and out-of-the box, it automatically deploys every branch to it's own "Preview" environment. This has been game changing for me, inverting my review workflow. Before I look at the code, I typically test out the UX changes live.

[eyilmaz]

There is also a service which can be integrated into your pipeline: https://diffy.website. You can take screenshot from your production or stage environment and compare them with your feature/PR builds.

[WorldMaker]

A different tack: are you getting the frontend PRs because they want you to review UI changes?

As a backend developer there's a certain "thoroughness" you have drilled into you about making sure backend PRs are "rock solid" and everything is well reviewed (because sometimes PR is the only place you catch things that would cost considerable problems in Production). That's a great mindset to have! It's not necessarily a mindset you need to bring to frontend PR reviews.

For UI changes, those often get plenty of "review" in User Acceptance Testing. We want to think that UAT is a deep process that tests every aspect of the app, and sometimes we build complex QA scripts for UAT testers, but in most cases in my experience the things that UAT are most reliable for are primarily fairly shallow, and UI/visual bugs are the number one thing UAT tests find quickly and reliably. (You don't feel a lot of UAT pressure on the backend which is why sometimes you feel a need to get backend PRs as solid and comprehensive as possible. The opposite happens in frontend work: the PRs can be a bit "sloppier" because UAT often is a strong "canary" for bugs/mistakes/glitches/tweaks.)

As often a full stack developer my experience is that backend and frontend focused PRs have very different needs in the PR process. If there's a strong place to apply that "backend mindset" to frontend PRs it is in a lot of the same things that likely make you a good backend programmer: frontend JS has all the same memory and performance management tasks of any other garbage collected language you work with. For instance: are your frontend engineers considering the O-complexity of their algorithms and their memory storage? That may even be the reason they want someone more "backend minded" reviewing "frontend PRs". They may be too busy worrying about the UI/visual changes of their tasks and don't have as much bandwidth or need to pay as much attention to how the code is working at a performance level and that sort of "cross-pollination" between mindsets in PR benefits the project (users experience those performance/memory issues pretty directly, but it can be hard to focus in planning UI/frontend tasks).

[denysvitali]

Cypress can take screenshots too, maybe you can use the screenshot function and store the artifact in your CI job. This way you can include a before / after screenshot of your change in the PR

[anecd0te]

My org requires screenshots and/or gifs in the PR. Tooling is great, but not everything needs automation all the time when a little bit of manual work needs to be done anyway.