To understand where the two wildly different viewpoints come from, you need to have some understanding of history.
The concept of unit testing originated in the Smalltalk community. There are a lot of differences between Smalltalk and the languages that most people build large projects with these days, but the relevant one here is that Smalltalk is dynamically typed. And specifically (so that this doesn't end up turning into a static-vs-dynamic flamefest, which is not the intention here,) it has no compiler capable of verifying type correctness prior to execution. This is the primary problem that unit testing was originally created to solve: catching details like type errors that the compiler would have caught for you, if you'd been able to use one. And that makes a lot of sense, when you don't have a compiler available.
The problem is, a bit later down the line, a bunch of Java folks (who did have a compiler and a strict type system available) heard about the idea. Only they didn't really understand it, most likely because the problem it's designed to solve does not exist in Java. They thought, "oh, look at this! We can test our software's functionality before we use it, and that will help catch bugs!" even though the type of bugs that unit testing was invented to catch don't happen in Java.
Java being very popular, the idea got picked up and spread quickly, and the claims about it continued growing more and more grandiose, until eventually we ended up with ridiculous things like Uncle Bob claiming that, if you write all your code with a proper testing methodology:
think about what would happen if you walked in a room full of people
working this way. Pick any random person at any random time. A minute
ago, all their code worked.
Let me repeat that: A minute ago all their code worked! And it doesn't
matter who you pick, and it doesn't matter when you pick. A minute ago
all their code worked!
Just in case you didn't catch the claim there, unit testing is supposed to be a magical thing that will make all your code work!
This is complete nonsense, of course. If all of your tests pass, that means that all of your tests pass, nothing more, nothing less. And specifically, it does not mean that:
- your tests correctly describe what the code is supposed to be doing in the first place
- your tests cover every possible error case
- your tests, being code too, are free from errors themselves. (Follow that one to its logical conclusion and you get stuck in infinite recursion. It's tests all the way down!)
Also, bear in mind that your unit tests only cover the things you thought to write tests for. These are, of course, the things that were on your mind when you were writing them, areas where you anticipated would likely cause problems. These are areas you're paying attention to, which you're likely to get right in the first place. As any experienced developer will tell you, the majority of bugs (not all, of course, but a good majority) come from cases you never anticipated, which is why they turn out buggy. Tests are far less useful there.
There's another serious problem with unit testing, one of those issues that you don't really notice as a problem until your project gets really big and then it's too late, which is that changing requirements requires changing code, which breaks your tests. Sometimes it can break a non-trivial fraction of your tests, like 10% of them. And if you follow Uncle Bob's advice and write "every year... thousands of tests" like he exults about, eventually you have a whole lot of tests, enough that 10% of that whole lot is still a whole lot.
And the thing is, you just intentionally changed something. Unit testing is supposed to help you not accidentally make a change that breaks something, but you just changed something intentionally. And now you have hundreds or thousands (or more) of failing tests screaming at you, and you have to go through each one and individually, manually verify whether or not that test is still valid according to the new requirements. (And for the ones that aren't, you might well have to write new tests to replace them!)
And the interesting thing is, long before Uncle Bob started making his ridiculous claims about unit tests magically making all your code work, long before unit testing spread to Java and from there to the rest of the programming world, long before Java even existed in the first place, the whole concept was already known to be a silly idea by people who actually understood programming!
It is now two decades since it was pointed out that program testing
may convincingly demonstrate the presence of bugs, but can never
demonstrate their absence. After quoting this well-publicized remark
devoutly, the software engineer returns to the order of the day and
continues to refine his testing strategies, just like the alchemist of
yore, who continued to refine his chrysocosmic purifications.
-- Edsger W. Djikstra. (Written in 1988, so it's now closer to
The reason why there are two wildly different viewpoints out there regarding unit testing is that some people have enough perspective, and enough knowledge of history and/or of the fundamentals of computer science and engineering, to understand these principles and see the basic truth behind all the snake oil.
And some people don't. What they see is that on some small project they've been working on, at some point they happened to catch a nasty bug one time with an automated test. Or they know someone who did. Personal experiences loom large in our memory--that's basic human psychology. That's the thing that they really remember, and so they think it has to be some wonderful, magical thing, logic and reason notwithstanding.
They hold to the concept of unit testing with dogmatic fervor, and like any dogma, its Absolute Truth is necessarily stronger than any fact. Just look at how often TDD proponents pull out the old "if you don't like it/if it doesn't work for you, you must be doing it wrong" argument when confronted with the facts. That's not a logical argument; that's an emotional attack meant to shut down logical discussion. And it works far too well (again, basic human psychology,) which is why people keep using it.