Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tremor – The React library to build dashboards fast

tremor.so

Post reply on HN
Print view View original

61–70 of 84 posts

Re: Tremor – The React library to build dashboards fast

#61

Post by Scarblac »

nraf wrote: post #48
Capricorn2481 wrote: post #45

Earlier quoted context omitted.

> disables input when disabled is passed That's exactly the kind of test double I'm talking about

Can you elaborate on what’s problematic with this test? Testing that the component does what expected based on input is telling me the component is working as expected.

The developer that forgets to make disable work, will also forget to write this kind of test for it. Once the behaviour is added, it'll never be randomly removed again so the test isn't needed then. It looks nice but never helped find a bug.

Re: Tremor – The React library to build dashboards fast

#62

Post by latchkey »

Scarblac wrote: post #59
latchkey wrote: post #30

Earlier quoted context omitted.

> 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 te…

I've given an example of a whole repository, that is now 4 years old, full of the types of tests you're talking about. It isn't that hard.

If the desired behavior is changing, then the test should fail and yes, you need to rewrite it. That's how testing works.

Re: Tremor – The React library to build dashboards fast

#63

Post by latchkey »

Scarblac wrote: post #61
nraf wrote: post #48

Earlier quoted context omitted.

Can you elaborate on what’s problematic with this test? Testing that the component does what expected based on input is telling me the component is working as expected.

The developer that forgets to make disable work, will also forget to write this kind of test for it. Once the behaviour is added, it'll never be randomly removed again so the test isn't needed then. It looks nice but never helped find a bug.

Part of the complexity of integrating a form library with a ux library is passing all of the correct properties around between the two. In this case, I wasn't doing that correctly and it resulted in a bug where disabled was not being set correctly. Someone filed a bug. The bug was fixed and a test was written to ensure that this doesn't happen again in the future.

You can read the history here: https://github.com/lookfirst/mui-rff/issues/455

If you're working with people who randomly 'forget' things while they are doing development, then I guarantee that you're working with people who also write buggy code. In fact, in this case, it was ME who wrote that buggy code. I own it. Not all code gets 100% coverage and sometimes things get missed. That is ok. What is not ok is skipping tests because you might forget something and therefore think it isn't worth writing tests at all.

I consider buggy code the act of developers writing the code at least 2x instead of 1x. If you or your company is paying someone $X a year to write code once and they are actually writing code more than once, then I would highly suggest you look for new people to work with because that is a terrible return on investment.

If your developers are writing tests, along with their code, then the code is far more likely to be correct and better thought out and less buggy than code that was just hand tested as they developed it. Speaking of that 2x example, I'd rather pay someone 2x the amount of time to write code, with tests, than the other way around.

Re: Tremor – The React library to build dashboards fast

#64

Post by Jenk »

latchkey wrote: post #43
renegade-otter wrote: post #41

Earlier quoted context omitted.

My personal projects generally have a better test suite than what I do for work. First of all, I do it at my own pace, but more importantly - it makes the whole thing possible, as you said. The nature of a personal project is such that I may not come back to it for months, sometimes even years. The first thing I always do is run the test suite. It's my lodestar. It helps me understand what state the project is in so…

People are often given timelines at work that don't include testing. As a believer in agile, I generally push back hard to include testing. I'd rather dole out incomplete MVP's with tests and fewer features than to skip tests entirely just to hit crazy timelines with a buggy product. Experience says this almost always has positive long term results.

just don't segregate testing, it is integral to the production of quality software and therefore should be considered the same as, say, asking to skip using a keyboard in an attempt to save time.

Re: Tremor – The React library to build dashboards fast

#66

Post by cbovis »

zeroonetwothree wrote: post #54
latchkey wrote: post #52

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.

This has been my experience in the past with a heavily snapshot covered codebase. Class names can change, the structure of your HTML can change, the underlying CSS can even change and the end result is still the same because you were just refactoring. At a large enough scale it can be painful to have hundreds of snapshots break for a simple change - especially when you add required code review by others into the mix.

Currently figuring out a strategy for introducing testing into an already large codebase and being very cautious of snapshot tests because of this. Experimenting with visual regression testing but early indicators suggest it could get very expensive if we're not careful about what is covered.

Re: Tremor – The React library to build dashboards fast

#67

Post by williamdclt »

c-hendricks wrote: post #49
latchkey wrote: post #27

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?

Is your point that snapshot tests are not perfect? I don’t think anyone argues against that.

Are they useful and do they prevent bugs is the better question

Re: Tremor – The React library to build dashboards fast

#68

Post by Scarblac »

latchkey wrote: post #63
Scarblac wrote: post #61

Earlier quoted context omitted.

The developer that forgets to make disable work, will also forget to write this kind of test for it. Once the behaviour is added, it'll never be randomly removed again so the test isn't needed then. It looks nice but never helped find a bug.

Part of the complexity of integrating a form library with a ux library is passing all of the correct properties around between the two. In this case, I wasn't doing that correctly and it resulted in a bug where disabled was not being set correctly. Someone filed a bug. The bug was fixed and a test was written to ensure that this doesn't happen again in the future. You can read the history here: https://github.com/loo…

> if you're working with people who randomly 'forget' things while they are doing development, then I guarantee that you're working with people who also write buggy code. In fact, in this case, it was ME who wrote that buggy code. I own it.

We all write bugs, we're human and it's hard to think of everything all of the time.

My point was, when we make a thinking error that causes us to write a bug, that same thinking error means we also don't write that test that could find it. If you had thought of writing a test for the disabled thing when you wrote the code, you also would have written it correctly because you would have had that case in mind then.

Now you have a test, but because someone reported the bug and you fixed it. Now it's almost certainly not useful to have anymore.

I believe in automated tests, but for tricky logic mostly.

Re: Tremor – The React library to build dashboards fast

#69

Post by nraf »

Scarblac wrote: post #61
nraf wrote: post #48

Earlier quoted context omitted.

Can you elaborate on what’s problematic with this test? Testing that the component does what expected based on input is telling me the component is working as expected.

The developer that forgets to make disable work, will also forget to write this kind of test for it. Once the behaviour is added, it'll never be randomly removed again so the test isn't needed then. It looks nice but never helped find a bug.

An example where it’s helped me personally is when migrating from Angular Material to Ant Design. The test cases gave me confidence the expected behaviour was preserved

Re: Tremor – The React library to build dashboards fast

#70

Post by Scarblac »

latchkey wrote: post #62
Scarblac wrote: post #59

Earlier quoted context omitted.

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 te…

I've given an example of a whole repository, that is now 4 years old, full of the types of tests you're talking about. It isn't that hard. If the desired behavior is changing, then the test should fail and yes, you need to rewrite it. That's how testing works.

It's not hard, but they just make the build of our monorepo take longer and longer without finding actual bugs, in my experience. I feel most unit tests should be commented out once the thing under test is done.
Post reply on HN