> Dunno about this. In my experience test makes it harder to add code, since usually way too many tests test implementation details. I'm puzzled by opinions li

> Dunno about this. In my experience test makes it harder to add code, since usually way too many tests test implementation details. I'm puzzled by opinions like this. So you see tests as a nuisance that hinder your productivity, rather than a safety net that ensures that the system behaves the way it's supposed to, giving you the freedom to safely make changes and peace of mind that they will make the product better for your users. > Pair this with some process heavy and written in stone agile methodology and arcane CI environment (which shows test failures on a tv in the break room). And you can't easely change the tests since that code is not your team's. This sounds like you've had a bad experience in poorly managed teams, which has nothing to do with testing. > Even using the concept of 'code smell' makes my alarm go off. We would have been better off without all these missused rule of thumbs and aphorisms. Eh, as with anything, these things can be abused. But when you've worked in any industry for some time, you accumulate "rules of thumb" and wisdom from experience, and experienced developers can indeed point out "code smells" that are worth discussing at the very least. Best practices exist for a reason, and while there are always reasons to not follow them, deciding to do so requires as much experience as what it took to discover and understand them. Blindly following any methodology is not good, but the benefits of testing are pretty clear. There are details and tradeoffs worth considering, but I just don't understand the argument that tests make your job more difficult. Testing is a part of your job as much as writing production code is.