My point is that unit tests aren't cost-free, and their ROI is awful for most things.
Step 1: If you're thinking about how a code api should act, sketch it out inside a test.
Step 2: If you're about to jump into a repl and poke at your code, open a unit test instead.
Now you've simply replaced other activites at no net cost to you. My core takeaway is that everyone tests their code somehow. You're best off if you can automate that process. Don't obsess over it (I almost never test my html/views), but try to find opportunity.
The models testing is obvious. What you're referring to there is controller testing. In Rails/Rspec, the way you do that is by mocking/stubbing the models (so you're only testing the controller logic). Then you pass in the parameters that would come in from the web, and check that the controller code (which should be fairly straightforward) behaves appropriately.
This article explains this approach quite clearly: http://www.patmaddox.com/blog/2007/9/15/easy-controller-test...
I don't know what he's using there at Justin.tv, but most languages that are more rigid (than Smalltalk or Ruby for example) are certainly not quite as nice for unit testing.