3 ms·

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 usual

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

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