But I think unit/module/integration test do not solely serve the purpose of testing. They are important also as a safeguard for future changes to guarantee that existing functionality is not broken by new code and changes on existing code. Tests should be written with this objective and to blindly increase coverage.
It is also not surprising that projects written in languages with strong compile time checks and guarantees require less tests (i.e. Zed is written in Rust).
This has been my experience as well, I feel the pain when writing that test is way more complicated and time consuming then fixing the bug or writing the feature.
I would add that for me a good question to ask before writing a particular test is: "if I did this in some side project in my spare time, would I bother writing this test now or would I find an easier test that is good enough or would I even refrain from writing this test?"
Because if I get paid by the hour, invested time is usually not the biggest concern I have (unless it is kind of urgent for some reason).
Not that this the only factor but it gives me a direction to decide :)
I love test. And as a frontend developer, I know it is hard to test UI. I always try to extend the limit. It have been both successful and painful.
Yeah I know test is not the answer to design problems. It is just a question to all answers.
I am writing only tests which made me happy and give me confidence. It is not a duty. Just a tool to help me. If it doesn't help, I just delete the useless automated tests. (and jusy test them manually)
I agree with the arguments.
But I think unit/module/integration test do not solely serve the purpose of testing. They are important also as a safeguard for future changes to guarantee that existing functionality is not broken by new code and changes on existing code. Tests should be written with this objective and to blindly increase coverage.
It is also not surprising that projects written in languages with strong compile time checks and guarantees require less tests (i.e. Zed is written in Rust).
Guess there could be a correlation between software quality and tests, but maybe not as strong a causal link.
This is how I feel about TypeScript.
This has been my experience as well, I feel the pain when writing that test is way more complicated and time consuming then fixing the bug or writing the feature.
I have a similar experience so I strongly agree.
I would add that for me a good question to ask before writing a particular test is: "if I did this in some side project in my spare time, would I bother writing this test now or would I find an easier test that is good enough or would I even refrain from writing this test?"
Because if I get paid by the hour, invested time is usually not the biggest concern I have (unless it is kind of urgent for some reason).
Not that this the only factor but it gives me a direction to decide :)
I strongly agree with you. :)
I love test. And as a frontend developer, I know it is hard to test UI. I always try to extend the limit. It have been both successful and painful.
Yeah I know test is not the answer to design problems. It is just a question to all answers.
I am writing only tests which made me happy and give me confidence. It is not a duty. Just a tool to help me. If it doesn't help, I just delete the useless automated tests. (and jusy test them manually)