The point is not to tell you that you should never have unit tests. They can be useful (though rarely). I'm not suggesting that if you write a new datastructure

The point is not to tell you that you should never have unit tests. They can be useful (though rarely). I'm not suggesting that if you write a new datastructure that you shouldn't have a few tests that only really exercise one or a few methods. They do not guarantee the program does what it's supposed to do. "without having to do integration test or user tests" doesn't exist. It's fiction. It leads to all the bad places to be in software development. It leads to you explaining to a manager or PM that "it matches the requirements, I don't accept that you have a problem", when the software just lost your firm a million dollars. Software development in reality : you do not get accurate requirements. Your design does not match reality (and the 1st version is so far off it's not even internally consistent: it likely can't be built at all, never mind perform it's intended function). Getting better at software development, after a while, stops being about improving your ability to collect requirements. It does not make your v1 designs better. You simply learn to deal with change, to provide good places for as-yet-unknown changes in your designs, to go out weekly and ask for changes in requirements, knowing that either your design can accommodate them or you'd rather hear them sooner than later.