I agree. But I think that testing exists to produce correct code. But obviously correct code is better than incorrect code. ☺️
Don't modify the horse to fit the cart.
That's true. Testability is not the most important thing. Working software should be the main goal.
This discussions always remind me of the "Is TDD dead" videos. And to be clear: it's an important discussion. That's why I am posting questions like this. People need to see both sides of this discussion.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Uncle Bob said (I'm paraphrasing) that if he had to choose between having a complete test suite and the code it tested, he'd prefer the tests because he could use the tests to recreate the implementation but he can't do much with a pile of code without tests.
I agree with the point he was trying to make.
Q: If you get hit by a bit tomorrow what would the next guy or gal who has to maintain your code want to see? Clean code following SOLID principles with "good" tests? That would be my hope if I was that next guy.
The longer I do this (programming), the less patience I have for code without tests.
The "bus factor" is my motive for leaving extensive intent inline comments and external documentation. Tests shouldn't have to be used to recreate intent, which is the ingredient from which we recreate code. In fact, I'd even say that having to recreate intent from tests is only slightly less soul-sucking than recreating from raw code. Therefore, I'd say it's a terrible motive to writing tests.
That said, yes, tests are virtually always something you should have as part of your code base.
Funny thing is, you'd think all this would be obvious...but our industry has a strange habit of adopting methodologies for their own sake, instead of because how they can benefit our project.
Auxiliary point, "TDD" drives me a little crazy, because it is a particular methodology of programming that doesn't work for all projects. I've worked on a few where TDD would have been more of an obstacle than an asset. We still do testing in those projects, but it isn't "TDD" per-se. In short, Testing != TDD. :)
Auxiliary point, "TDD" drives me a little crazy, because it is a particular methodology of programming that doesn't work for all projects.
It's very important to stress that. I don't think there are a lot of practices and methodologies that work for every project. Every project is different. They use different languages, frameworks and libraries. There are really big and very small projects. From a few hundred lines of code, to millions.
I said it before and I will say it again: Use the right tool (or framework or methodology) for the right job. Don't be dogmatic.
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. But I think that testing exists to produce correct code. But obviously correct code is better than incorrect code. ☺️
That's true. Testability is not the most important thing. Working software should be the main goal.
This discussions always remind me of the "Is TDD dead" videos. And to be clear: it's an important discussion. That's why I am posting questions like this. People need to see both sides of this discussion.
Uncle Bob said (I'm paraphrasing) that if he had to choose between having a complete test suite and the code it tested, he'd prefer the tests because he could use the tests to recreate the implementation but he can't do much with a pile of code without tests.
I agree with the point he was trying to make.
Q: If you get hit by a bit tomorrow what would the next guy or gal who has to maintain your code want to see? Clean code following SOLID principles with "good" tests? That would be my hope if I was that next guy.
The longer I do this (programming), the less patience I have for code without tests.
The "bus factor" is my motive for leaving extensive intent inline comments and external documentation. Tests shouldn't have to be used to recreate intent, which is the ingredient from which we recreate code. In fact, I'd even say that having to recreate intent from tests is only slightly less soul-sucking than recreating from raw code. Therefore, I'd say it's a terrible motive to writing tests.
That said, yes, tests are virtually always something you should have as part of your code base.
Funny thing is, you'd think all this would be obvious...but our industry has a strange habit of adopting methodologies for their own sake, instead of because how they can benefit our project.
Auxiliary point, "TDD" drives me a little crazy, because it is a particular methodology of programming that doesn't work for all projects. I've worked on a few where TDD would have been more of an obstacle than an asset. We still do testing in those projects, but it isn't "TDD" per-se. In short, Testing != TDD. :)
It's very important to stress that. I don't think there are a lot of practices and methodologies that work for every project. Every project is different. They use different languages, frameworks and libraries. There are really big and very small projects. From a few hundred lines of code, to millions.
I said it before and I will say it again: Use the right tool (or framework or methodology) for the right job. Don't be dogmatic.