Currently, in our code base, we have unit tests written for each class and its classes coverage is close to 89%. Now, my task is to increase code coverage wrt functional tests which is about 56%.

Functional tests have end to end flows, and I am not sure how to really increase the coverage. I feel it's an incomplete question and also my effort so far is negligent.

Where should I start? (Also, should I exclude classes like utilities, loggers, DAO etc? What determines the exclusions?)

  • 1
    I think you should push back on measuring code coverage for functional tests, for the same reasons I stated in sqa.stackexchange.com/a/25007/246.
    – user246
    Commented Feb 24, 2017 at 20:00

1 Answer 1


There are a few factors to consider.

  1. Is code coverage an adequate functional test?
  2. What is the end goal?
  3. 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:

  1. Unit test and ensure your code works and is up to standards.
  2. Functional test to ensure the specs are covered adequately and user friendly.
  3. 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?
  4. 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.

  • Can you cite some example online? Here, its looking too complicated to understand how to expand first of all.
    – xploreraj
    Commented Feb 27, 2017 at 5:47
  • I'm trying to talk generically, while there are a wide variety of approaches that would constitute a variety of paths to go about this. Simple terms is perspective, you slice the application into perspectives and don't look at code coverage. Code coverage can come after you get solid perspectives down. (functional usage perspective, unit testing methods for test driven development, Usability testing, etc...)If you have a specific software methodology approach you are following please add that for more specific answers regarding functional/code coverage approach options within the SDLC.
    – mutt
    Commented Mar 6, 2017 at 22:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.