Random Thoughts about Testing

I had an interesting casual chat with a co-worker who has been working as a front-end engineer for more than 10 years. The primary goal was to ask about the effectiveness of unit testing, but other topics were also discussed during the chat.

• effectiveness vs. efficiency: How are they different from each other? When it comes to effectiveness, it's more about the degree of an impact caused by an action. But when we talk about efficiency, it's mainly about how much time you put into a task. Let's say you finish a task in 5 minutes which normally takes 40 minutes to finish. Then you show high efficiency. But can we say that the effectiveness is also high? Probably not, because if you just put any random amount of time to finish a random task that causes almost zero impact to a project, then the effectiveness is very low although the efficiency you showed was very high. So they're not co-related.
• Unit testing: Should we always start from unit testing when we say we're doing TDD? Let's say we make a button component. It's a button with a pretty red background. You write a unit test to prove that it's a pretty red button. Okay, I can see that by snapshot testing. But according to the TDD process, there's a pyramid of testing stages that after the unit test, there comes another testing phase such as component and integration, and then e2e testing. If we can prove that the button works well during the integration testing, do we need to care about the single button by unit testing? How deeper do we need to go down when we're saying a component is working well and not spending so much time on writing or managing testing code? Unit testing cannot tell that the component actually doing its contract successfully. So maybe we need to care more about the component or integration testing which requires an explicit input and output by using mocks or dummy data.
• Law of the instrument: To plan or think about the project architecture, you may start researching the other options except for the tools that you already know. But to be honest, those tutorials won't be pretty much helpful as you expected since most of the tutorials is targetting basic-level learners. It's quite hard to find the gems for developers beyond the intermediate stage of their careers. Sometimes it needs to spend more than 15 hours to find one hidden gem from the conference playlist. There're many tools, libraries, methodologies when you plan the project architecture. Your preference should come later than the goal of the project when choosing the stacks. Why? You probably have heard of a famous analogy that when you have a hammer, you just nail it everywhere. But are you going to still use the hammer if you just discovered a screwdriver? Law of the instrument, we always remember this rule when we're working as a developer. I understand you like the tool, and I can see the tool is popular since it's easy to use and find someone who uses it. But does it also mean that it's the best solution to the problem that you're going to solve? If you know Angular and React, both, that's really good. But please don't think you should always have to make a choice and stick to it. Why not trying to mix both benefits and trying something new to find out a more effective way to solve the problem?