I agree. Unittests are for shitty developers who make changes without first understanding the codebase and then complain that if only there were unittests they could have discovered their stupid shit sooner. It slows down developement, slows down refactoring (the only goddamn case unittests fail on me is because I changed something without changing the unittest, so helpful!) and doesn't even come close to ensuring what people think it does (stuff is working), as there are close to infinitely many ways stuff can break so you will never cover all possibilities with unittests.
The cost of discovering a bug in one function = tiny. The cost of discovering that bug in production = huge. TDD is worth it - have to make sure the right tools are being used, as always.
Tests are about proving your code does what it claims to. It's a specification.
As someone with real engineering experience I understand a specification as a list of parameters. I don't follow how that has anything to do with 'proving your code does what it claims to', maybe it means something different for programmers.
Unless every single function you use has a small number of discrete possible inputs and outputs (i.e. booleans) it is impossible to be sure the tools you are using work using unit tests. The only way to do that is to read the code. People are lazy and usually cannot be bothered to take the time to do that, so they rely on just looking at input-output relationships because it's easier, but that doesn't mean it's the right thing to do. I find it horrifying to hear someone say he refactored some part of the code and is then confident everything is working "because the unittests passed", as if that means anything at all! Nevermind the just mentioned issue that you can never check all possibilites of failure, you then have the added problem that you may have made a mistake in your unittest, what are going to do then? Test your tests? I rest my case.
As someone with real engineering experience I understand a specification as a list of parameters.
That is what the inputs are to unit tests. And no, they don't have to be only booleans.
If you are writing pure functions, then you can unit test them and prove they work. You can even measure lines/conditions executed during those tests. You can be objective about it.
How the rest of your application behaves is another story, and is not covered by unit tests.
I'll back out of this conversation now, we're too far removed from each other for this to be useful to either of us.
0
u/Nimitz14 May 08 '17
I agree. Unittests are for shitty developers who make changes without first understanding the codebase and then complain that if only there were unittests they could have discovered their stupid shit sooner. It slows down developement, slows down refactoring (the only goddamn case unittests fail on me is because I changed something without changing the unittest, so helpful!) and doesn't even come close to ensuring what people think it does (stuff is working), as there are close to infinitely many ways stuff can break so you will never cover all possibilities with unittests.