There are a few factors to consider.
- Is code coverage an adequate functional test?
- What is the end goal?
- What is the most efficient and productive way to accomplish your goal?
The main goal of functional testing is to ensure the desired functionality works the way it's intended to work. Whether this takes 4 lines of code or 400 lines of code is irrelevant. The user might utilize the same 20 lines of code 400 times in different ways and be happy with it or they may have 400 different complaints for the same 20 lines of code. Thus functionally testing the code and calling it "covered" defeats the whole point of functional testing in this case.
The end goal is a solid application which matches the defined specifications and satisfies the end users needs. You could add that following good practices is a part of it as well. This being said, unit testing in it's very nature should accomplish the result of ensuring the code works as intended and it follows proper coding standards. There is no need to "repeat" a unit test on the gui (except like javascript or something that is gui manipulation).
So the end goal would better be suited to:
- Unit test and ensure your code works and is up to standards.
- Functional test to ensure the specs are covered adequately and user friendly.
- If you want a measurement then see how much code is touched by functional testing and ask yourself, if everything is accomplished by x% is the rest of the code bloated or not usable? Maybe refactor?
- The #3 question should hopefully come back with a standardized structure, security measures, boundary cases, etc...in which case you could add those functional tests as well if you desire.
The main point though is a different perspective. Functional testing should never be focused on the code, but on the experience of the application functionality. Otherwise you are spending alot of time doing unit testing on the gui instead of actually ensuring quality in the application.