3 ms·
It's a common fallacy among some software developers that since TDD forces you to write small units of code (since you have to write small unit tests then natur
by gumballindie 3y ago
It's a common fallacy among some software developers that since TDD forces you to write small units of code (since you have to write small unit tests then naturally the units you test will also be small) then your code will be easy to maintain. It also forces dependency injection in OOP and a couple other design patterns. I've seen code written as if by one's feet without unit tests that worked better than code with 90% test coverage. In a few cases tdd was the go to practice for sloppy devs. Somehow they thought that writing tests will account for lack of skill. But guess what? Tests were sloppy too.
- wizofaus 3y agoI don't think anybody could claim TDD will make a sloppy dev write good code. Though there's half an argument for getting more experienced/skilled devs to write the tests and the more junior or less capable ones to fill in the actual working implementation (but I'll be honest, I've never seen this work in practice over a prolonged period).
- gumballindie 3y ago> (but I'll be honest, I've never seen this work in practice over a prolonged period) Me neither. I think that can only work when the same thing has been done countless times before. But at that point you can just use someone else's work, either via a library or an off the shelf product, instead of reinventing the wheel. And then you are left with working only on something that's new. Which invites the question - how can you test that which you don't know you need? In the context of unit testing that is.