Good Software Development Habits

"Know when you're testing the framework's capability. If you are, don't do it."

Hard disagree on that. Frameworks change over time. How certain are you that they won't make a seemingly tiny design decision in the future that breaks your software?

One of the most valuable things tests can do for you is to confirm that it is safe to upgrade your dependencies.

If all your test does is duplicate tests from dependency that might be a waste of time... provided that's a stable, documented feature and not something that just happens to work but isn't necessarily expected stable behavior.

But you shouldn't skip testing something because you're confident that the dependency has already covered that.

The tests should prove your software still works.

I very much agree with you on this. Upgrading dependencies is something you do and you are responsible for if it broke things. I'd frame it slightly differently though. I think you should have some tests that tests the full functionality the user will experience, regardless where the pieces come from. And don't go our of your way to mock or stub something because it's not written by you. There is no reason to avoid useState() being executed in your test suite as long as your code actually depends on it and your test doesn't get super expensive to execute or write because of it. Now, if something is expensive, try to limit testing it only to the top of your testing pyramid. But you should till test the full stack because that's what you are gonna ship!

I think it probably is saying: don't write a "useEffect runs when its dependencies change", write a "User is redirected to their accounts page after loging in", and you are testing both your own code and the framework's routing / side effects handling / state tracking, etc.

Integration tests for complex flows inadvertently tests your dependencies, which as you say is awesome for when you have to upgrade.

If you are going to write a test that tests the frameworks capability, submit a PR to the framework.

The only part that's relevant to you is how it interfaces with your own code. If their behavior changes but your code still does exactly what you want it to, the test shouldn't fail.

I don't think submitting a PR to a framework is a good strategy:

1. They may not accept the PR

2. Even if they do accept that PR, there's no guarantee that in two years time some maintainer will decide to change that behaviour (and update or discard the test you contributed) anyway.