I think that sometimes people lose sight of the fact that other people are different. You may not care for sports cars while someone else might. Doesn't make o

I think that sometimes people lose sight of the fact that other people are different. You may not care for sports cars while someone else might. Doesn't make one of you superior to the other. Neither one of you can say that the other is wrong and should have made the choice you did. It is the same thing with many programming methedologies, including unit tests. Maybe unit tests work well for large companies, and I would think they might be ideal for parts of certain types of server applications. But I have tried the methodology, and found that it slows me down and produces lower quality code. For me, it produces a lot of false positives as the some number of unit tests become out of date each sprint, and the significantly increased overhead slows down development significantly which means less quality functionality per unit time gets developed. I've tested this theory with a real product written %100 solely by me, and found that the actual results in production where there were no unit tests and no design documents (but lots of design "notes") resulted in a shocking result: Not a single exception over a large deployment among thousands of customers and many months and only one reported bug which at the end of the day is actually working correctly but the design decision was not clearly thought out and the software does something the user doesn't expect in a corner case. Here I see people talking about refusing to hire people who don't believe in Unit tests, and everywhere else on the planet I see people talking about Unit tests as if they are a religion, and as if nobody could write competent code without using them. But realize this, every programmer is different, and the path to the highest quality code per unit time may not be via unit tests.