Live data from Hacker News

Tremor – The React library to build dashboards fast

tremor.so

51–60 of 84 posts

Re: Tremor – The React library to build dashboards fast

#51

Earlier quoted context omitted.

Good question. `@testing-library/react` and jest to run it. snapshots and a bunch of action code too. There are more modern frameworks now too that can be used for integration tests, but I haven't bothered yet as the snapshots have almost always caught the issue. It boggles my mind that react.dev doesn't start off teaching, with writing tests.

Are snapshot tests the things that fail because they can't tell "background-color: #ff0000" and "background-color:#f00" are the same?

It depends on the tool doing the diff on the snapshot and what you're putting into it to begin with. https://jestjs.io/docs/snapshot-testing

The components I test all use classes, so there aren't embedded styles. Occasionally the generated class names change across different versions, but it is a small price to pay and easy enough to just update the shots.

I'd also argue that I'd want that snapshot to fail. I'd want to know why someone made that change, especially if they were going in the other direction... f00 -> ff0000.

Re: Tremor – The React library to build dashboards fast

#52
post #50

Earlier quoted context omitted.

Are snapshot tests the things that fail because they can't tell "background-color: #ff0000" and "background-color:#f00" are the same?

Yes, that’s right… they are of dubious utility imho.

4 years of maintaining a react project downloaded 40k times a month argues otherwise.

Re: Tremor – The React library to build dashboards fast

#53

Earlier quoted context omitted.

We have hundreds of tests for our client side projects (web app, mobile app), and they definitely do more than what you describe. Some are simple (although very few are as simple as your example) and some are complex, depending on the portion of the app being tested. Some are basically integration tests for components/widgets, where it runs it in isolation to test the inputs and outputs. Others are more like traditio…

Could you give an example? Most UI tests I see are either a) trivial/tautological, b) test implementation details, or c) doesn’t actually even test the UI , i.e “what is visually painted on-screen.”

At work we use snapshot tests to see visual changes to ui. It helps a lot with code review especially with adding edge case data to tight designs.

We use ui tests specifically for testing accessibility, analytics and data passed along during navigation.

We use fixtures for all of this.

None of these tests really help with bugs. What they do help with is:

- Making sure the ui stays really decoupled from the business logic. This helps a lot with getting the data unit tested which does help a lot with bugs.

- Making sure that analytics and accessibility are not forgotten about. This helps a ton when refactoring.

- Making the intent of the code really clear during review.

It takes a bit of practice and being ruthless about removing/fixing stuff that’s not helping. I have found it makes it much easier for new developers to work, review code and understand how the code is organized. YMMV.

Re: Tremor – The React library to build dashboards fast

#54
post #50

Earlier quoted context omitted.

Yes, that’s right… they are of dubious utility imho.

4 years of maintaining a react project downloaded 40k times a month argues otherwise.

It probably works ok for a solo project but IME with large scale codebases snapshot tests are awful. You update some implementation detail of a common shared component and suddenly 5000 tests break despite the look and behavior being unchanged.

Re: Tremor – The React library to build dashboards fast

#55

I've gotten so jaded on these "batteries included! everything you'll ever need!" component libraries over the years. Inevitably you'll run into a component that is half-baked or incompatible with your architecture, which forces you to install a 3rd party alternative. Then it happens again. And again... Eventually you're left pulling in this huge library with 2MB of CSS just for the four components you're still using…

I agree with you. But I think this is a symptom of a different problem: Building admin panels with UI tools instead of config-driven tools.

While component libs like this can be used for consumer-facing UI, when we talk about "dashboards" it's also often backoffice admin panels.

You shouldn't be reaching for hand-writing UI design & logic in that scenario. You should be looking for an admin panel interface tool. Laravel has these in spades: Nova, Backpack, and Filament are the big three. You write some code and some logic tied to it, and the tool creates the UI for you. This lets you get back to writing code for the actual customers instead of for business processes.

These can be used for consumer facing panels too, but with less control over the design, they're not really intended for it.

But the JS ecosystem insists on being fragmented, so everything is rewritten manually.

"Batteries included" needs a lot more than just batteries (the UI components).

Re: Tremor – The React library to build dashboards fast

#56

Earlier quoted context omitted.

4 years of maintaining a react project downloaded 40k times a month argues otherwise.

It probably works ok for a solo project but IME with large scale codebases snapshot tests are awful. You update some implementation detail of a common shared component and suddenly 5000 tests break despite the look and behavior being unchanged.

Give me an example. Those components depend on this common shared component... if you do something that changes that shared component in such a way that it causes other snapshots to fail, I'd absolutely want to know about it. That's the whole point of dependency failures.

My dependency is on MUI, which is a massively used common shared component library. If MUI changes, and it breaks my snapshots, I'd absolutely want to know about it.

Re: Tremor – The React library to build dashboards fast

#59

Earlier quoted context omitted.

I have yet to see a good frontend test, but I'm waiting to be enlightened. For the most part, it just seems to be things like "if they click this button, make sure this div is gone." That smells like a test double to me.

> I have yet to see a good frontend test You haven't written one yourself? Is your theory that since you can't write one, they aren't possible? All my tests are good enough to ensure that if I upgrade a library or change underlying functionality, something breaks if the output is not expected. That is my primary concern and that is what I test for.

I know how to make tests for _logic_, that's usually in Typescript functions (e. g., React hooks).

But for components, that call some of those hooks and then render some JSX, I've never been able to write a test that found a bug later on. Every single time one of them failed, either the change made was so large that the whole build failed to compile anyway, or it was because there was new desired behaviour and the test needed changing, not the code.

If a type of test doesn't help find bugs, it's a waste of space.

Re: Tremor – The React library to build dashboards fast

#60

I started a react component library project that has been going for 4 years now and gets about 40k downloads a month. If it wasn't for my test suite, things would have been a giant mess long ago and I probably would have abandoned it. I can't think of doing a react project without a test suite because over time, any dependencies you have (including on react) will end up breaking things in ways that you don't know. Wi…

What is your test suit like?
Post reply on HN