I used to do TDD, I found that it didn't work that well for me.
I still think that the code base you work on dictates how you should be testing. It also dictates which testing strategy I use.
I test for different things when writing C than I do when I write Python for example. My testing strategy is different if I write a networked C application compared to if I write a Ruby on Rails app.
Also the tools I have available to me when writing the code dictates how I will test, which is tied into which language I write in.
And I really disagree that code has to be awful because you are not forced to write unit tests. I work with a team of 4 other experienced and responsible programmers. We actually don't have to have rules that force us to do anything. We are responsible enough and experienced enough to know what to do and when to do it.
40 - 50 % of our code base doesn't have a single unit test, because it doesn't have to have any. Are we infallible, no. Does mistakes happen? Yes. Do we sometimes go back and add unit tests to code that we thought didn't need any. Yes, it happens.
Would unit tests have saved us sometimes? Yes. If it would have, then we are responsible and go back and add that test.
I think the point was more that many people can’t write unit tests because their code is so shoddy that it’s basically impossible to do so.
It sounds like you and I share a similar methodology. I don’t write unit tests for all my code. In fact if I had to guess, I’d say I generally test less than 25%.
But I do write all my code such that it’s capable of having unit tests written for it.
In many codebases that’s just not possible. The developers have spent all their time writing and none of their time thinking. It’s one big yarn ball that’s impossible to write unit tests for. For these people, forcing them to write tests up front would have resulted in a much cleaner code base.
I do enjoy TDD, in that it makes it easier for me to ensure that I implement everything I need.
I completely agree that it's not always necessary, but I definitely find it a useful tool.
That being said, TDD with ML applications is a bunch trickier, as you'll normally have functions/classes which take an unfathomably looooooonnnnngggg time to run.
40-50% is perfectly acceptable for your team by the sounds of it. In other teams with varying degrees of experience and skill things are a bit more wild.
The fact that you can add tests means your code is at least somewhat scaffholdable and that is the important part for testability.
For the record I do TDD maybe 20% of the time, I mostly just use it in tough problems where I don't know what to do next.
I still think that the code base you work on dictates how you should be testing. It also dictates which testing strategy I use.
I test for different things when writing C than I do when I write Python for example. My testing strategy is different if I write a networked C application compared to if I write a Ruby on Rails app.
Also the tools I have available to me when writing the code dictates how I will test, which is tied into which language I write in.
And I really disagree that code has to be awful because you are not forced to write unit tests. I work with a team of 4 other experienced and responsible programmers. We actually don't have to have rules that force us to do anything. We are responsible enough and experienced enough to know what to do and when to do it.
40 - 50 % of our code base doesn't have a single unit test, because it doesn't have to have any. Are we infallible, no. Does mistakes happen? Yes. Do we sometimes go back and add unit tests to code that we thought didn't need any. Yes, it happens.
Would unit tests have saved us sometimes? Yes. If it would have, then we are responsible and go back and add that test.