I'm focused on developing and expanding my knowledge and skills. Enjoying new challenges. I'm assuming that there are no stupid questions, there are only silly answers.
First of all great article. I would like to add mine observation about unit tests.
In discussion with the business about writing unit tests necessity, I used to use the argument that unit test help us discover a bug earlier and at the end of the day they are cheaper than manual testing. Costs always play role in discussions with the business. 😉
About modularization and dependencies, as you said, unit tests improve the architecture of our code. It is easier to follow SOLID principles when we're writing unit tests. In my opinion, we can treat unit tests as a guard of SOLID principles in our code. If something is painful to test it smells like not SOLID enough.
About code which doesn't require unit tests, I totally agree with you that we should be aware of the amount which is needed to cover a particular piece of code with a test and in the case when costs are higher than benefits, we should resign of writing it. BUT it could be dangerous in some cases. We can end with code which is hard to test due to its dependencies, which is fragile and not maintainable. We can end a vicious circle. On the one hand, we want and need to write a unit test and on the other hand, writing it is very, very time-consuming. I think that sometimes we should pay the costs. The longer we're waiting, the cost is rising. If we are talking about some legacy code, which doesn't change at all, I think we can deal with this. When we need to maintain the legacy code, we should pay and write unit tests.
To sum up, great article. I've read it with real pleasure. Cheers.
Hey Rafal, thank you!
The importance of testing depends on business priorities. After all, tests consume time, and sometimes the business decides to stay on the side of development speed, rather than quality.
Sometimes, when this happens, the code becomes untestable and also harder to change, but at this time refactoring and tests cost even more. They are a long-term investment. This is a good time to make the statement about the future costs you were talking about, and start to introduce testing from the most critical parts.
I'm focused on developing and expanding my knowledge and skills. Enjoying new challenges. I'm assuming that there are no stupid questions, there are only silly answers.
Hi Elena.
First of all great article. I would like to add mine observation about unit tests.
In discussion with the business about writing unit tests necessity, I used to use the argument that unit test help us discover a bug earlier and at the end of the day they are cheaper than manual testing. Costs always play role in discussions with the business. 😉
About modularization and dependencies, as you said, unit tests improve the architecture of our code. It is easier to follow SOLID principles when we're writing unit tests. In my opinion, we can treat unit tests as a guard of SOLID principles in our code. If something is painful to test it smells like not SOLID enough.
About code which doesn't require unit tests, I totally agree with you that we should be aware of the amount which is needed to cover a particular piece of code with a test and in the case when costs are higher than benefits, we should resign of writing it. BUT it could be dangerous in some cases. We can end with code which is hard to test due to its dependencies, which is fragile and not maintainable. We can end a vicious circle. On the one hand, we want and need to write a unit test and on the other hand, writing it is very, very time-consuming. I think that sometimes we should pay the costs. The longer we're waiting, the cost is rising. If we are talking about some legacy code, which doesn't change at all, I think we can deal with this. When we need to maintain the legacy code, we should pay and write unit tests.
To sum up, great article. I've read it with real pleasure. Cheers.
Hey Rafal, thank you!
The importance of testing depends on business priorities. After all, tests consume time, and sometimes the business decides to stay on the side of development speed, rather than quality.
Sometimes, when this happens, the code becomes untestable and also harder to change, but at this time refactoring and tests cost even more. They are a long-term investment. This is a good time to make the statement about the future costs you were talking about, and start to introduce testing from the most critical parts.
Exactly, this was my thought ;)