I agree with the spirit of the post, essentially the best code is the code that's never written. That said, I think we're missing the point to testing: the power it gives us to shape our code by writing our tests before each small piece of production code. In other words, TDD.
I would argue most of the value of tests isn't in validating the that our software still works. That's just a fantastic side-effect. The real point to writing tests is in allowing them to drive the design of our code. TDD forces you to write each function from the perspective of the person calling the function. It doesn't care about implementation details, instead it cares about the interface.
I'm still amazed at the difference in code quality between when I practice TDD and when I don't. It's huge. And the funny thing is TDD usually ends up taking me less time then not writing tests at all, considering all of the time it takes me to debug my untested code.
Front-end Engineer and Tester. I have a course at https://learn.webdriver.io and I do free coding tutorials at https://www.youtube.com/user/medigerati/
I totally agree with you. However, I feel that TDD should be used by developpers that are already experienced with the library/framework they're using. The reasoning behind this is that by writing their tests before hand, beginners often end up rewriting their tests when they realize that the library/framework doesn't behave as they have expected. And basically, this takes away precious time that they could have been invested in learning how to use the library/framework better.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with the spirit of the post, essentially the best code is the code that's never written. That said, I think we're missing the point to testing: the power it gives us to shape our code by writing our tests before each small piece of production code. In other words, TDD.
I would argue most of the value of tests isn't in validating the that our software still works. That's just a fantastic side-effect. The real point to writing tests is in allowing them to drive the design of our code. TDD forces you to write each function from the perspective of the person calling the function. It doesn't care about implementation details, instead it cares about the interface.
I'm still amazed at the difference in code quality between when I practice TDD and when I don't. It's huge. And the funny thing is TDD usually ends up taking me less time then not writing tests at all, considering all of the time it takes me to debug my untested code.
This is a great point, thanks for sharing!
I totally agree with you. However, I feel that TDD should be used by developpers that are already experienced with the library/framework they're using. The reasoning behind this is that by writing their tests before hand, beginners often end up rewriting their tests when they realize that the library/framework doesn't behave as they have expected. And basically, this takes away precious time that they could have been invested in learning how to use the library/framework better.