Ultimately, the only tests that matter are system tests (feature tests). These are the tests that ensure you're delivering the correct result to the customer. In practice I find unit level testing a pointless exercise.
I totally agree that feature or behavioural tests validate that customer requirements are met. But you shouldn't (and probably can't) test more in-dept behaviour in these.
For example, I wrote a shopping basket system for a site last year. There were feature tests in there - "When I click the 'add to basket' button then I should see the item in the basket" sort of thing. Those are great. But I also wrote a whole bunch of unit tests for this - checking that calculations were correctly performed, and the adding and removing items worked correctly, and that tax was applied according to the correct rules, and so on. These tests are super-quick to run and provide a lot of confidence that the API contract is being adhered to. We could have completely switched out the back-end storage for a third-party API or something, and the tests would still be applicable.
There are loads of reasons to test behaviour in layers - I agree that you can easily over-invest in effectively pointless tests, and I've seen that everywhere. But don't discard all unit tests as worthless.
Feature tests often need to span large parts of an application, so there is a often significant amount of overhead (both code and test-time) in repeating identical-except-for-one-value.
Feature tests often can't test the corner cases of internal code. For example, one hallmark of quality software is that it degrades gracefully in the presence of unexpected inputs. So, while the UI might prevent out-of-range values, programmers often choose to also check value ranges at, for example, the top of a stored procedure. This means that you can't test that code with an app-level feature test because a correct UI won't let you enter values to trigger the stored proc's failure case.
Another big issue is the combinatorial explosion. If you have a processing pipeline, like filters in a sound or image processing app or validation and authorization checks in a line-of-business app, the number of configuration and data values that need to be tested for each stage needs multiply together if you only feature test. Unit testing allows you to make sure each of the stages works "well enough"[1], then you can use far fewer integration and feature tests to make sure that the stages cooperate properly and that system requirements are met (two overlapping, but different, concerns).
[1] However the engineer, team or industry defines "well enough".
[Edit: split up the wall 'o text]
Time-consuming nature of feature tests can be an issue, but often is mitigated by automated testing on commit, merge, etc. But not always of course.
I agree with combinatorial explosion however it can sometimes be mitigated by procedurally generating tests.
Feature tests are fine for simple or small apps, but I wouldn't rely on them for the bulk of my testing in any significant app.
The unit level testing in our other projects helped me figure out very quickly what was going on. I could read the method names and it was the the cliff notes to a book. And then based on those test passing, I would assume the notes were correct. I'm sure the experience isn't the same for everyone and I'm still very new to TDD, but after having one really good experience, I'm all for it. My tests have tests.
Secondly, system tests won't identify the specific "faulty part". Unit tests will. That can save quite a bit of time, assuming you have enough of both types of tests.
Thirdly, unit tests inform good component design. If your unit test is hard to write, the component under test is typically either not structured well, highly coupled to other code, or some other deficiency that will result in more bugs over time, which all become readily apparent when you try to unit test it. You will end up refactoring the code under test and it will often "feel better" for lack of a better description.
Fourthly, if all you rely on is integration/acceptance/"comprehensive" tests, you will have tests that run some parts of the code hundreds of times over in a test suite run, which is incredibly wasteful. For example, a workflow integration test which requires someone to log in and try various things, will have to run the login/authentication code dozens of times, when you already know it works.
Doing it with unit tests simply means that you'll end up writing the test, refactoring and then completely REwriting the tests AGAIN to get them all to pass because you're changing the method contracts and the objects being mocked.
Tests that fail every time you refactor are totally meaningless and a waste of time. They don't detect bugs. They just detect changed code.
I agree. This is where I think the distinction between classical and mockist testing [1] is useful. These days, most TDD involves mocking or stubbing every single dependency, effectively turning your units into a white box - "isolated TDD." When one has code whose implementation is known by and manipulated by client code, refactoring will almost certainly break stuff.
Why would you want to liberally refactor code when you know you will break 10 of your tests and have to rewrite them?
One frequently sees hardcore TDD advocates patting themselves on the back for isolating everything, because... now they can swap the database for a third-party API, in-memory store, remote service, or whatever. Really? You're going to replace the database with something that has wildly different reliability constraints? And why would you ever need to replace your database with a remote third-party service? I'm sure it can be useful, but for most people, YAGNI. Perhaps I've merely not worked on enough Web Scale™ or Big Data™ projects.
[1] http://martinfowler.com/articles/mocksArentStubs.html#Classi...
I think this comes about because tests are written against every class in your system. I find unit tests are far more useful if you focus on testing abstractions rather than every single class e.g. you have a reporting abstraction in your code, instead of testing every class used within that abstraction you only test the public API that you want to expose. This allows you to do black box testing which is infinitely better when it comes to refactoring, you should be able to restructure the internals of that particular API without having to change your unit tests at all.
My feeling is that a lot of the frustration with TDD at the moment is that people are writing tests for every public method in their system. If you focus more on the behaviour of your abstractions you gain a lot more freedom when refactoring and can greatly reduce the number of tests you write without reducing coverage.
Yes, this is exactly what they're useful for. Unfortunately, if you have a big ball of tightly coupled muddy code and you're working on prying it apart and creating useful abstractions you can't use unit tests to get there.
The only way you can do test driven refactoring in that case is to create system level functional tests and then rework the code underneath them. Once you've got decent abstractions and a solid set of APIs and only then you can start writing unit tests against them.