On the contrary. Unit testing is exactly for exposing that sort of thing. (Actually, I see more problems with cute off-by-one bugs than null pointers per se, but still.) They should not be thrown away.

There are ways to do it and ways not to do it, though. A good framework should be exhaustively unit tested. Individual components that use that framework should be lightly unit-tested (rather than having the framework heavily mocked) and more attention should be spent on integration/acceptance tests.

That sounds daft. One of the main benefits I can see with unit testing is that if you re-factor components below, then you can be reasonably sure it will work the same way afterwards. Why would you throw that away?

You have got it all very wrong. Not a single thing you've said is correct.

He may be confusing TDD with unit test, but he's right that unit tests tend to expose design rather than bugs. Unit tests are typically tightly coupled with the underlying implementation, and so unforeseen cases in the code (that will cause a bug) tend to be unforeseen cases in the test too.

Finding bugs is not the primary purpose of unit tests.

No, you are confusing unit testing with TDD. Unit testing is just testing units of code. TDD is the religious practice adhered to by some followers of Agile that is a "design tool" where you write tests first. http://en.wikipedia.org/wiki/Test-driven_development

>not for exposing nullpointer exceptions

If you are using a language primitive enough to have null pointer exceptions, then using unit tests to try to detect some of them is a perfectly reasonable thing.