When I present our case (400 acceptance tests, 30 unit tests) I often get asked
"How you can refactor without unit tests?". Well, it's easy, if the refactoring did not break my acceptance tests then I am safe. It seems that there is common misbelief that you need unit tests in order to refactor.
Lets look at the some view points:
1) Unit testing supports design (building the knowledge)
True, though you could as well use any other "tool" like CRC cards and you would not increase the mass of your "manufacturing equipment" than can be seen as waste. Acceptance testing also supports design by giving the focus and telling you when you have "done" with the story from functionality perspective.
2) Unit testing does not ensure that the totality works
... so you need the acceptance testing anyway.
3) Acceptance testing is slow, so therefore it is better to do unit testing
If something is slow you should not do it? That's just weak. You should look into tools like Selenium Grid.
4) Fixing acceptance tests takes so much time, refactoring unit tests is faster
So maybe your acceptance tests are not very good? Changes in implementation (not behavior) should not break your acceptance tests.
5) Unit testing is not really that much about testing
... but it may be a good tool for learning. Still unit test coverage does not mean anything really (neither does acceptance test coverage).
Of course you may have as much unit tests as you ever like - just give it a thought before jumping into it. :)
Update: Some people have taken this post as "Unit testing is something that should not be done at all". That is NOT my message - I think we need delicate balance and I would pursue that by "outside in"-approach where you take the user's view and start approaching the system from there, working from Acceptance test towards Unit tests. If you approach automation by implementing "inside out" unit tests you may get lost with the unit testing adventure.