3 ms·

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 wo

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. Without those tests, you can't be sure of upgrades... which you're forced to do because your users will want to do things like upgrade react. So... any project like this... in order for me to ever add it to my own project or depend on it in any way, really needs a test suite. The test suite for this project is pretty much non-existent, which is a huge bummer should should be a huge red flag for anyone who thinks about using it. You're just going to end up with broken code.

code_witch_sam 3y ago
i only skimmed the home page, but it seems far too opinionated for general use. if you're starting fresh and plan to use tremor as your all-encompassing ui kit, it seems fine. but at that point, why not grafana, retool, or some other no-to-low-code dashboard solution?
- latchkey 3y ago
  It is fine for a quick one off project, but if you're going to depend on anything over the long term, you have to be able to upgrade it. Especially in JS land where things change almost weekly. 99% of my releases have been simply about dealing with changes of dependencies. I wouldn't be confident to do a release if I didn't have a test suite. You're right on the point of using another low code solution though... it still opens you up to dependency issues. You might also want this as a product with its own skinned UX/UI that you have full control over. Third party 'commercial' products won't always give that to you.
appplication 3y ago
Not a react dev, but having a comprehensive test suite is the only reason I feel comfortable pushing code changes and upgrading dependencies. It is difficult at first to build the habit and discipline to always write comprehensive tests for new code, but it is very worth it.
- latchkey 3y ago
  In JS land it is especially important and honestly one of the least done things, which is sad and a source of why things are always breaking randomly.
  - appplication 3y ago
    I work primarily with data scientists in python, so I understand a similar pain.
    - latchkey 3y ago
      The mind boggles on how we are using python for ML/AI... I bet stable diffusion would get the hands right if we had better unit tests. /s
ketzo 3y ago
What does your test suite look like? (What's the library is maybe a better question)
- latchkey 3y ago
  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.
  - c-hendricks 3y ago
    Are snapshot tests the things that fail because they can't tell "background-color: #ff0000" and "background-color:#f00" are the same?
    - jtms 3y ago
      Yes, that’s right… they are of dubious utility imho.
      - latchkey 3y ago
        4 years of maintaining a react project downloaded 40k times a month argues otherwise.
        zeroonetwothree 3y ago
        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.
        latchkey 3y ago
Capricorn2481 3y ago
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.
- latchkey 3y ago
  > 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.
  - Capricorn2481 3y ago
    No, that's not what I meant. I mean tests are great on the backend, but I've never seen them prevent a bug on the frontend, especially in react where it's usually obvious what effect your changes will have. In fact, many frontend tests don't even truly test the UI
    - latchkey 3y ago
      https://github.com/lookfirst/mui-rff/blob/master/test/Autocomplete.test.tsx https://github.com/lookfirst/mui-rff/blob/master/test/Autoco...
      - Capricorn2481 3y ago
        > disables input when disabled is passed That's exactly the kind of test double I'm talking about
        latchkey 3y ago
        And? There was an actual bug filed around that and the issue was resolved with a test that ensures it doesn't happen again. That is all I care about. Make sure we don't make the same mistake twice and that over time things continue to work with new versions.
renegade-otter 3y ago
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 I can confidently pick up where I had left it. It is also my requirements documentation - as code.
- latchkey 3y ago
  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.
  - Jenk 3y ago
    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.
moneywoes 3y ago
What is your test suit like?

code_witch_sam 3y ago

i only skimmed the home page, but it seems far too opinionated for general use. if you're starting fresh and plan to use tremor as your all-encompassing ui kit, it seems fine. but at that point, why not grafana, retool, or some other no-to-low-code dashboard solution?

latchkey 3y ago
It is fine for a quick one off project, but if you're going to depend on anything over the long term, you have to be able to upgrade it. Especially in JS land where things change almost weekly. 99% of my releases have been simply about dealing with changes of dependencies. I wouldn't be confident to do a release if I didn't have a test suite. You're right on the point of using another low code solution though... it still opens you up to dependency issues. You might also want this as a product with its own skinned UX/UI that you have full control over. Third party 'commercial' products won't always give that to you.

appplication 3y ago

Not a react dev, but having a comprehensive test suite is the only reason I feel comfortable pushing code changes and upgrading dependencies. It is difficult at first to build the habit and discipline to always write comprehensive tests for new code, but it is very worth it.

latchkey 3y ago
In JS land it is especially important and honestly one of the least done things, which is sad and a source of why things are always breaking randomly.
- appplication 3y ago
  I work primarily with data scientists in python, so I understand a similar pain.
  - latchkey 3y ago
    The mind boggles on how we are using python for ML/AI... I bet stable diffusion would get the hands right if we had better unit tests. /s

ketzo 3y ago

What does your test suite look like? (What's the library is maybe a better question)

latchkey 3y ago
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.
- c-hendricks 3y ago
  Are snapshot tests the things that fail because they can't tell "background-color: #ff0000" and "background-color:#f00" are the same?
  - jtms 3y ago
    Yes, that’s right… they are of dubious utility imho.
    - latchkey 3y ago
      4 years of maintaining a react project downloaded 40k times a month argues otherwise.
      - zeroonetwothree 3y ago
        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.
        latchkey 3y ago

Capricorn2481 3y ago

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.

latchkey 3y ago
> 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.
- Capricorn2481 3y ago
  No, that's not what I meant. I mean tests are great on the backend, but I've never seen them prevent a bug on the frontend, especially in react where it's usually obvious what effect your changes will have. In fact, many frontend tests don't even truly test the UI
  - latchkey 3y ago
    https://github.com/lookfirst/mui-rff/blob/master/test/Autocomplete.test.tsx https://github.com/lookfirst/mui-rff/blob/master/test/Autoco...
    - Capricorn2481 3y ago
      > disables input when disabled is passed That's exactly the kind of test double I'm talking about
      - latchkey 3y ago
        And? There was an actual bug filed around that and the issue was resolved with a test that ensures it doesn't happen again. That is all I care about. Make sure we don't make the same mistake twice and that over time things continue to work with new versions.

renegade-otter 3y ago

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 I can confidently pick up where I had left it. It is also my requirements documentation - as code.

latchkey 3y ago
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.
- Jenk 3y ago
  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.

moneywoes 3y ago

What is your test suit like?