Code Covers Common Features / Parameters?
I am working on some code coverage for my applications. Now I know that code coverage is an activity related to the type of tests you are generating and the language you want to do code coverage in.
My question is, is there any possible way to cover some common code? As in, can we have a set of features / test cases that we can run (along with more specific tests for the application under test) to get code coverage, like 10% or more of the code?
Moreover, if I want to create a structure to cover the code, what is the best way to make it generic? Is it possible for some features to be automated or generalized?
source to share
I'm not sure if general coverage tools are the holy grail, for several reasons:
- Coverage is not a goal, but a tool. It tells you which parts of the code are not fully included in the test. It doesn't say anything about how good the tests are.
- The generated tests cannot guess the semantics of your code. A framework that generates tests for you can deduct meaning from reading your code, which in fact might be wrong, because the whole point of unittesting is to see if the code actually behaves the way you intended it.
- Since the automatic framework will create artificial turf, you can never tell that a piece of code has been tested with the correct unittest or superficially tested with a framework. I would prefer the unverified code to show up as uncovered, so I'm fixing that.
What you could do (and I did ;-)) is write a generic test for testing Java beans. Through reflection, you can test the Java bean against the Sun Java bean specification. The assertion that equals and hashcode are both implemented (or neither), see that the getter actually returns the value you insert with the setter, check if all properties have cleaners and setters.
You can do the same basic trick for anything that implements, such as "comparable".
It's easy to do, easy to maintain, and forces you to have clean beans. For the rest of the unittests, I try to focus on getting the important pieces tested first and foremost at every step.
Coating can give a false sense of security. Common sense cannot be automated.
source to share
This is usually achieved by combining static code analysis (Coverity, Klockwork, or their free counterparts) with dynamic analysis by running tests against a tool application (profiler + memory check). Unfortunately, it is difficult to automate test algorithms, most of the tools are "recorders" capable of recording traffic / keys / signals - depending on the domain and playing them back (with minimal changes / replacements like session id / user / etc.) )
source to share