There is not any official distinguished between code Coverage and Test Coverage. Some practitioner has expressed their difference opinion in terms of defining Code Coverage and Test Coverage.
Code coverage and test coverage metrics are both measurements that can be seful to assess the quality of your application code. Code coverage is a term to describe which application code is exercised when the application is running.

Whereas Test coverage refers to metrics in an overall test-plan. In this expert  response, you’ll learn how quality assurance professionals use both of these metrics effectively.

Another definition found over the google search as below;
Code coverage is a measure of how much code is executed during testing &
Test coverage is a measure of how many test cases have been executed during testing.

Lets know about  Code Coverage by definition more in details.
In computer science, code coverage is a measure used to describe the degree to which the source code of a program is tested by a particular test suite. A program with high code coverage has been more thoroughly tested and has a lower chance of containing software bugs than a program with low code coverage. Many different metrics can be used to calculate code coverage; some of the most basic are the percent of program subroutines and the percent of program statements called during execution of the test suite.

Basic coverage criteria

There are a number of coverage criteria, the main ones being:

• Function coverage – Has each function (or subroutine) in the program been called?
• Statement coverage – Has each statement in the program been executed?
• Branch coverage – Has each branch (also called DD-path) of each control structure (such as in if and case statements) been executed? For example, given an if statement, have both the true and false branches been
• executed? Another way of saying this is, has every edge in the program been executed?
• Condition coverage (or predicate coverage) – Has each Boolean sub-expression evaluated both to true and false?

[Taken from Wikipedia]

Simply put, code coverage is a way of ensuring that your tests are actually testing your code. When you run your tests you are presumably checking that you are getting the expected results. Code coverage will tell you how much of your code you exercised by running the test. Your tests may all pass with flying colours, but if you’ve only tested 50% of your code, how much confidence can you have in it?

The post Difference between Code Coverage and Test Coverage | Code Coverage VS Test Coverage appeared first on scmGalaxy.

What is Code Coverage
Code Coverage is an important measurement in Software Quality Engineering. While Software testing ensures correctness of the applications, a metric is required to track the What is Code Coverage Code Coverage is an important measurement in Software Quality Engineering. While Software testing ensures correctness of the applications, a metric is required to track the completeness and effectiveness of the testing undertaken. Code Coverage helps achieve reliable quality through identifying untested areas of the application.

Why Code Coverage
Software testing is a challenging function. The testers need to ensure complete functional and non-functional correctness of the product. Considering the complex workflows and use cases of modern day applications, the number of unique cases that the software can be used often run into millions, which is not feasible to be covered under testing exercise. The testers thus need to
– While Planning Tests
o Ensure covering all workflows in terms of decision trees in the code
o Ensure covering all data values – by identifying patterns rather covering millions of values
– While testing
o Ensuring the testing is completely exercising the whole application with planned and exploratory tests.

At the end of testing, the decision to stop testing and release the product still remains subjective, based on the presence or absence of bugs, inflow of new bugs, success rate of each test cycle, confidence rating of the testers or users, etc. Whereas the definitive metric of quantifying how much of the application was really tested, is missed.

Code Coverage is measured as quantification of application code exercised by the testing activities. Code Coverage can be measured at various levels – in terms of programming language constructs – Packages, Classes, Methods, Branches or in terms of physical artifacts – Folders, Files and Lines. For Eg. A Line Coverage metric of 67% means the testing exercised 67% of all executable statements of the application. A Code Coverage metric usually is accompanied by Code Coverage Analysis Report – which helps identify the un-tested part of the application code, thereby giving the testers early inputs for complete testing.

Benefits of Code Coverage

• Objective Indicator of Test Coverage of application code
• Pointers to uncovered Packages / Classes / Methods / Branches
• Pointers to uncovered Folders / Files / Lines
• Drill down to untested part of source code and devise new tests
• Early Indicator for Testing Quality and Fixing it by adding new tests.
• Remove redundancy in testing
• Increased Confidence for Releases

Test Your Test

Typical Emotional Storyboard

• Write Some code! Happy!
• Does it work? Sad!
• Write some test! Happy!
• Do they really test the code? Sad!
• Measure the Code Coverage! Happy!

Coverage Measurement

1. Shows Which line of code are executed
2. How much of your code is covered by your tests?
3. Your tests test your product
4. Coverage testing tests your tests

Goal

• 100%
• Coverage Ideal
• Not Always possible
• Can be expensive to achieve
• Design for testability

Good: Write more tests
Only way to truly increase code coverage

Bad
Excluding Code to boost Coverage

Types of Coverage

1. Statement Coverage
2. Branch Coverage
3. Path Coverage
4. Loop Path Coverage
5. Data – driven Code
6. Complex Conditionals
7. Hidden Branches

How; – Coverage Tools

1. Clover
2. Cobertura
3. Emma

The post What is Code Coverage and Why Code Coverage? appeared first on scmGalaxy.

EMMA is a tool for measuring coverage of Java software. Such a tool is essential for detecting dead code and verifying which parts of your application are actually exercised by your test suite and interactive use.
EMMA’s design strives for several, very elusive in their combination, goals:

• report rich coverage analysis data without introducing significant overhead during either build or execution time
• be useful in team development environments, while at the same time enabling fast individual develop-test cycle
• support quick development and testing of small standalone Java applications as well as scale up to massive enterprise sotfware suites containing thousands of Java classes

Advantages of Emma over other coverage tools

EMMA differs from other coverage tools in its extreme orientation towards fast iterative develop-test style of writing software. JVM Profiler Interface (JVMPI)-based tools do not require an instrumented source build, but the runtime overhead of running with JVMPI on is empirically known to be very high and results in depressingly slow testsuite runs. For tools based on source code instrumentation, having to wait for a full source code rebuild just to check coverage metrics is not something a normal developer wants to do several times during a day. EMMA’s goal is to be so unintrusive that frequent daily checking of coverage numbers becomes second nature to every developer on the team, if not a completely automatic byproduct of every test run.

Install and Configuration

Method 1: To run on Command Line.
Copying emma.jar to <your jre dir>/lib/ext/ directory for whichever JRE you use from command line.
Method 2:
Still, if you are wary of adding a third-party library as a standard JRE extension, just make sure that all your EMMA command line invocations add emma.jar to the JVM classpath:
>java -cp …/lib/emma.jar <emma or emmarun command>

Implementing EMMA with Application

• On the Fly Mode – Based suited for Standalone Application
• Offline Mode – Best suited for J2EE framework based application

Implement EMMA in J2EE project {WebLogic, Websphere, Tomcat, JBoss, …}?

There are very less opportunities given by Emma that  you would be able setup emma for J2EE Project on the fly mode. The reason behind this to fact that many J2EE features requires specialized class loading that will happen outside EMMA instrumenting class holder. The server might run fine but you will unlikely to get EMMA report.
So, based Procedures to Instrument your classes prior to deployment (offline mode); offline instrumentation always follows the same compile / instrument / Package / deploy / get coverage / Generate report sequence.
There are following steps need to follow to implement EMMA in J2EE based project…

• Use EMMA’s instr tool to instrument the desire classes. This can be done a post compilation step, before packaging. However many users also find it convenient to let EMMA process their jars directly (either in place, using overwrite mode, or by creating separate instrumented copies of everything, fullcopy mode.
• do your J2EE packaging as normal, but do not include emma.jar as a lib at this level, that is, within your .war, .ear, etc;
• locate whichever JRE is used by the container and copy emma.jar into its <jre dir>/lib/ext directory. If that is impossible, add emma.jar to the server classpath (in a server-specific way);
• deploy your instrumented classes, .jars, .wars, .ears, etc and exercise/test your J2EE application via your client-side testcases or interactively or whichever way you do it;
• to get a coverage dump file, you have three options described. It is highly recommended that you use coverage.get  control command with the ctl tool available in v2.1.

Notes:

Reference:
http://emma.sourceforge.net/faq.html#q.runtime.appservers
http://emma.sourceforge.net/reference/ch02s03.html#tool-ref.instr.outmodes

Emma Integration with other tools

Emma Integration with Sonar
Emma Integration with Hudson
Emma Integration with CruiseControl

jar instrumentation using Emma

http://primates.ximian.com/~flucifredi/emma-HOWTO.html
http://emma.sourceforge.net/reference/ch02s03.html#tool-ref.instr.outmodes
http://primates.ximian.com/~flucifredi/emma-HOWTO.html
http://groovy.329449.n5.nabble.com/EMMA-Code-Coverage-has-problem-with-Groovy-classes-td360560.html

The post Overview of EMMA | Code Coverage Tool – EMMA appeared first on scmGalaxy.

1.       Configure maven clover plugin.

2.       Build the all components with clover enabled.

3.       Deploy the clover enabled build to test server.

4.       Run the tests.

5.       Create & Review the Code Coverage Report.

Configure Maven Clover Plugin

Configure the maven plugin in pom.xml .If you are having multi module projects; you can configure the plugin in parent-pom instead of modifying each module’s pom xml.

Build all components with clover enabled.

Run the following command.

  “mvn -U clover2:setup package clover2:aggregate”

                If you got something like this

[INFO] Loaded from: C:\Documents and Settings\Administrator\.m2\repository\com\cenqua\clover\clover\2.6.3\clover-2.6.3.jar

[INFO] Clover: Commercial License registered to ABC Corporation.

[INFO] Creating new database at ‘C:\p4_depot\trunk\4A\target\clover\clover.db’.

[INFO] Processing files at 1.5 source level.

[INFO] Clover all over. Instrumented 5 files (1 package).

[INFO] Elapsed time = 0.532 secs. (9.398 files/sec, 812.03 srclines/sec)

Congratulation, you get clover work with your source!!

Deploy the clover enabled build to test server.

Deploy the Clover enabled build to the server. The same process as normal

Copy the Clover registry file to the appropriate directory on each of the test servers

The registry file is the DB file create during compile, defined by initstring parametersclover‐setup task, this needs to occur after the Clover build is complete, and before you run your tests

Background: the Clover initstring

FileName: xxx.db

At build time, Clover constructs a registry of your source code, and writes it to a file at the location specified in the Clover initstring. When Clover‐ instrumented code is executed (e.g. by running a suite of unit tests), Clover looks in the same location for this registry file to initialise itself. Clover then records coverage data and writes coverage recording files next to the registry file during execution

Notes: gives the folder contains the registry file full control permissions

Recommended Permissions

Clover requires access to the Java system properties for runtime configurations, as well as read write access to areas of the file system to read the Clover coverage database and to write coverage information. Clover also uses a shutdown hook to ensure that it flushes any as yet unflushed coverage information to disk when Java exits. To support these requirements, the following security

permissions are recommended:

grant codeBase “file:/path/to/clover.jar” {

permission java.util.PropertyPermission “*”, “read”;

permission java.io.FilePermission “<>”, “read, write”;

permission java.lang.RuntimePermission “shutdownHooks”;

}

Grant Permissions to clover.jar

Edit the java.policy file of the java runtime on the test server

%JAVA_HOME%/jre/lib/security

Copy clover.jar and license file to the java runtime class path of the test servers

%JAVA_HOME%/jre/lib/ext

Run the test suite

Run the test suite as normal. Either automation test case or manual test case.

Create Code Coverage Report

Copy the coverage recording files to build machine.

Once test execution is complete, you will need to copy the coverage recording files from each remote machine to the initstring path on the build machine in order to generate coverage reports.

Background: CoverageRecording Files

Filename:xxx.dbHHHHHHH_TTTTTTTTTT or clover.dbHHHHHHH_TTTTTTTTTT.1 (where HHHHHHH and TTTTTTTTTT are both hex strings)

CoverageRecording files contain actual coverage data. When running instrumented code, Clover creates one or more Coverage Recorders. Each Coverage Recorder will write one CoverageRecording file. The number of Coverage Recorders created at runtime depends the nature of the application you are Clovering. In general a new Coverage Recorder will be created for each new ClassLoader instance that loads a Clovered class file. The first hex number in the filename (HHHHHHH) is a unique number based on the recording context. The second hex number (TTTTTTTTTT) is the timestamp (ms since epoch) of the creation of the Clover Recorder. CoverageRecording files are named this way to try to minimise the chance of a name clash. While it is theoretically possible that a name clash could occur, in practice the chances are very small.

CoverageRecording files are written during the execution of Clover‐instrumented code. CoverageRecording files are read during report generation or coverage browsing.

Run the generating report goal to create the report.

                                “mvn clover2:clover”

The post Clover and Maven working with Distributed Applications appeared first on scmGalaxy.