←back to thread

361 points mmphosis | 1 comments | | HN request time: 0.001s | source
Show context
simonw ◴[] No.42165825[source]
"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.

replies(3): >>42167251 #>>42167793 #>>42168677 #
1. ervine ◴[] No.42167793[source]
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.