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.
That's exactly the kind of test double I'm talking about
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.
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.
Humans can't think of everything all the time - TDD guides you to think about one thing at a time.
No one is sitting there adding a disabled prop on their component that then disables an input for no reason. You had intent when writing it. It's possible that a co-worker distracted you, or you went for a break, or you went down another rabbit hole, and ended up skipping disabling the input based on the prop.
If you're practicing TDD, you would have written a failing test before creating the disabled prop. That test will continue to fail until the productive code has been written. It helps to protect against those thinking errors in the first place.
There is almost no way to even know what features they have, especially over time. Imagine that MUI added disabled in a new release and now my project isn't implementing it during an upgrade. TDD wouldn't have caught that.
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.
If the desired behavior is changing, then the test should fail and yes, you need to rewrite it. That's how testing works.