We are looking at updating our version of Django in the next year, and I am quite happy that we have a battery of unit tests that test how the features of the current version framework work against our code. I will be a lot more confident about upgrading versions because of what might appear at first glance as 'wasteful unittests'.
Also, as a rebuttal to the author, how can you expect crappy developers who write crappy tests to write good code?
I have had to do some major refactorings in projects I've worked on. They would have taken a lot longer to get right without the moderate-to-decent coverage of the test suites. Unit tests are a tool, like anything else in software development, but they're invaluable if used intelligently.
The more I become experienced with testing, the less I think the difference between functional, integration and unit tests is important. What's important is to have a test suite with good coverage that runs fast. I found that a mix of high level and lower level tests is a good way to achieve this goal and I don't mind mixing them in the same files. High level tests provide coverage more quickly, but some stuff, such as verifying that an exception is handled properly, is easier to test with unit tests.
He probably meant integration tests. Generally the standard practice in Django is to do integration testing at various levels. 1) Test the model with an in-memory database, or real database with rollbacks at the end of every test. 2) Test the views, generally using the actual models and db. I don't ever use mocks much when testing a Django project.
It wouldn't be too much trouble to mock the model when testing the views, but I don't bother and I don't imagine anyone else does either.
Also, as a rebuttal to the author, how can you expect crappy developers who write crappy tests to write good code?