linking instrumented code with clover db

[Phani Vempaty]

I've a question regarding how does the instrumented code get linked with clover db lcoation when the code is getting executed ?

I instrumented the source code using Clover and created a jar file out of it. I then use that jar file for running some tests which gives me the coverage reports when the reports are generated. I pass the "initString" which points to the clover db while instrumenting and also while generating the reports but not while executing the tests. I'm wondering how clover finds the clover db location without explicitly specifying it - everything is working fine and I don't quiet get only this step when the tests are executing.

PS: I don't have the clover db in the current directory - it is in a different place. So, I guess there is not way for it to check for the db in current directory to automatically find it. It is both a different name and in a different directory than the default ones.

[jjaroczynski · Accepted solution]

Hi,

AFAIK Clover remembers initString in the instrumented code so it is not necessary to provide it again for testing and generating report phases if project/files location does not change.

initString:

• is useful if you want to change default location of Clover DB for instrumentation phase,
• is necessary if your code is executed in different environment (e.g. deployed somewhere) or DB location has changed

Cheers,
Jacek

[Phani Vempaty]

Hi Jacek,

Thanks for the answer. It makes sense if it remembers initString in the instrumented code. So, it stores some kind of field for every class when it is instrumented with the value of initString ? - just wondering how it remembers in the instrumented code.

Thanks,

Phani.

[Nava Polk]

Do I have to use initString if I want to see coverage on tomcat server runing on the same machine?

[Marek Parfianowicz]

Hi Nava,

It depends on the following factors:

• whether you're using a relative or absolute path in initstring
• whether you want to copy clover.db to Tomcat's working directory
• whether you want to pass -Dclover.initstring system property

For instance:

1) If you define an absolute path to Clover database during instrumentation (e.g. <clover-setup inistring=""> for Clover-for-Ant or <cloverDatabase> for maven-clover2-plugin), then there will be no need to pass the -Dclover.inistring runtime property for Tomcat, as the path is encoded in instrumented classes and Tomcat runs on the same machine where build was performed.

2) If you define a relative path to Clover database during instrumentation, then you will have to either:

- copy clover.db to Tomcat's working directory so that it will "see" it under the same relative path or

- pass -Dclover.initstring property for Tomcat JVM pointing to Clover database location (inside a build workspace, for instance)

3) If you don't define initstring during instrumentation (so that Clover uses it's default location), then you'll have to copy clover.db to Tomcat's working directory or pass -Dclover.initstring property - see point 2.

Cheers
Marek

[Phani Vempaty]

Hi Marek,

Thanks for getting back on this. Regarding your questions :

• I'm using the path as "${basedir}/test/coverage/db/clover_coverage.db" for initstring.
• Yes, I'm sure it represents from the latest test execution. I even deleted all the coverage related files including the db for every run.

[Marek Parfianowicz]

Hi Phani,

I pass the "initString" which points to the clover db while instrumenting and also while generating the reports but not while executing the tests.

Clover must "see" the clover.db during application (or test) execution in order to record code coverage (unless you're using GROWABLE or SHARED coverage recorder type). Not providing initstring while executing the tests and having a different name/location of clover.db and still having some coverage data is quite suspicious.

• Are you using relative or absolute path for initstring during instrumentation?
• Are you sure that your report presents coverage data from your test execution and that Clover do not accidentally find some old coverage files from previous test runs and / or different clover.db locations?

Cheers
Marek

[Phani Vempaty]

Hi Marek,

Thanks for getting back on this. Regarding your questions :

• I'm using the path as "${basedir}/test/coverage/db/clover_coverage.db" for initstring.
• Yes, I'm sure it represents from the latest test execution. I even deleted all the coverage related files including the db for every run.

[jjaroczynski]

From what I understand Phani simply does not move anything (does not change relative location) between instrumenting, testing and generating report phases.

@Marek, can you answer the technical question "if and how Clover stores DB location during instrumentation phase"?

Thanks,
Jacek

[Marek Parfianowicz]

Hi Phani,

I'm wondering how clover finds the clover db location without explicitly specifying it.

Clover stores path to the database (initstring) in instrumented classes. Such path can be relative or absolute.

In case when a relative path is used, tests must run from the same directory where instrumentation was peformed. Otherwise, Clover won't be able to find the database.

In case when an absolute path is used, tests can be executed from any working directory.

It's always possible to override initstring defined during code instrumentation by providing the clover.initstring system property.

In your specific case, the ${basedir} is the absolute path of the project's basedir. So the "${basedir}/test/coverage/db/clover_coverage.db" initstring is an absolute path too. And such path is hardcoded in instrumented classes. That's why you didn't have to specify the initstring during test execution.

Cheers
Marek

[Phani Vempaty]

Thanks Marek and Jacek for the answers. I do have follow-up questions which might not be relevant to the title but asking it here.

• How do we specify the initstring while running tests.
• If there is a way to specify initstring while running the tests, is it specific to junit tests ?

I don't use junit for my tests. I just run my own tests which make use of the instrumented code and because the instrumented code contains information regarding the db, it was able to keep track for code coverage.

[Marek Parfianowicz]

Please have a look at this page:

https://confluence.atlassian.com/display/CLOVER/Working+with+Distributed+Applications

It's about distributed applications, but the chapter about initstring at runtime is applicable in other cases too.

[Phani Vempaty]

Thanks Marek for the pointers.

[Bhuvi Sundararaman]

Our's is a distributed application. I have intrumented source and deployed the instrumented jar on my client machine. Do I need to copy clover.db to the client location? because the intistring during instrumentation and execution are differnt..

[Marek Parfianowicz]

Yes. You have to copy clover.db file as it's required at runtime. You can override an initstring value from instrumentation by providing a runtime property 'clover.initstring=path/to/clover.db'. In case you have multiple databases you can use a 'clover.initstring.basedir' property.