Completely agree with this approach - recently I find that most of the tests I write are so-called 'integration' tests. I find these tests not only get more code coverage for fewer tests, but they more closely represent the real or implied external specification. In other words, they do a better job of verifying 'is the code correct' rather than 'is the code we wrote the code we wrote'.

I think the specification from elsewhere is all about the business value that the code delivers. At the end of the day, the business doesn't care about how exactly your code is decomposed into classes/functions/etc, the business cares about 'can I register a customer' and 'are customers prevented from writing to resources they only have read access to'. Of course there is some requirement for the code not to be a complete mess, as this has impacts delivering features and reducing bugs down the line, but with tests that sit closer to the value the code delivers than the structure of the code, you're free to refactor and the tests will tell you what you've inevitably broken. I find this considerably more valuable than unit tests.