Yes, unit tests are ideal for stuff like math libraries. A math function has a specification which will stay fixed for centuries, which you can easily test with

Yes, unit tests are ideal for stuff like math libraries. A math function has a specification which will stay fixed for centuries, which you can easily test with a unit test and in the mean while you can change the implementation to optimize performance. But this is not what coding looks like for the average IT job, which is more about routing data flows between a database and a web service endpoint or building web gui's. That code can also be unit tested and it can certainly have some benefit to do that while writing new code, because as other have said, it promotes a good coding style with small blocks of testable code, can serve as documentation etc. But for catching regressions, unit tests have much less value there. These unit tests will typically test only a few lines of business logic where database and web service calls have been mocked away. And chances are that the code will only need to be changed again when some requirement has changed. Which means that your unit test needs to be changed as well, or even completely rewritten. If you're not careful, maintaining your unit test suite can take you more time than updating the business logic. Which doesn't mean that you shouldn't write any tests at all, but for catching regressions, integration and system tests will have much more value.