Much of it depends on the mindset of people around you. I have to admit that I wrote unit-tests so that when other (lazy) developers change code that he/she di

Much of it depends on the mindset of people around you. I have to admit that I wrote unit-tests so that when other (lazy) developers change code that he/she didn't test, my unit-test will fail on his/her code. I like to view unit-tests (or integration, or whatnot) as a trap for these developers. The thing is... this is the kind of people that I had to deal with: lazy to test their code completely, write premature optimize code, have a bad taste in designing classes, don't understand OOP (write code in procedural style), and think that their code is "better". It's hard to reason with someone who thinks that Singleton is great because it saves memory even if you told the person that it's negligible. Or lazy instantiation of a meaningless member variable is great because it shaves 40% of object construction when the actual number of creating object is meaningless. At the end of the day they would say "but it's better... here's some numbers". I don't think I will change my mindset anytime soon. Especially when a couple days ago there were discussions on Reddit regarding "bad code", "bad programmers", and etc. I don't know how bad the situation in our industry as of right now because I'm seeing people writing more blogs/articles in favor of unit-tests (TDD or not) but from my personal experience and point-of-view, I saw a few good (and humble) developers out there and too many cocky ones. PS: It's worth to mention that based on my personal experience, good developers are usually the ones that have a family, e.g.: Paul Buchheit, Joshua Bloch, etc. They seem to be wiser and more patience.