Post Made Community Wiki by Loren Pechtel
source | link

Projects done for university classes differ vastly from business applications you'll write at your work. The difference is lifespan. How long does university project "live"? In most cases, it starts when you write first line of code and ends when you get your mark. You could say that, effectively it only lives for the time of implementation. "Release" is usually equal to its "death".

Software done for business surpasses that release-death point of university project and continues to live as long as business needs it to. Which is very long. When talking about money, nobody will spend a broken penny to have "cooler and neater code". If software wrote in C 25 years ago still works and is good enough (as understood by its business owner needs), expect to be asked to maintain it (adding new features, improving old ones - changing source code).

We come to one very important point - regression. At the place I work we have two teams maintaining two apps; one, wrote around 5-6 years ago with very little code tests coverage*, and second one, newer version of the first application with full-blown tests suite (unit, integration and what not else). Both teams have dedicated manual (human) testers. Want to know how long does it take to introduce a new, fairly basic feature for the first team? 3 to 4 weeks. Half of this time is "checking whether everything else still works". This is busy time for manual testers. Phones are ringing, people get upset, something is broken again. Second team usually deals with such issues in less than 3 days.

I by no means say that unit tests make your code error prone, correct or other fancy words you can come up with. Neither they make bugs magically disappear. But when combined with other methods of automated software testing, they make you applications much more maintainable than they would've been otherwise. This is a huge win.

And last but not least, comment by Brian which I think nails the whole issue:

(...) they do raise your confidence (or should...) that the code does what you designed it to do, and continues to do tomorrow what it does today.

Because between today and tomorrow, somebody might make tiny change which will cause the oh-so-important report generator code to crash. Tests push the odds that you'll find this out before your customer does a little bit to your side.

* They do slowly introduce more and more tests to their code base, but we all know how this stuff usually looks.