* `ut_coverage_cobertura_reporter` - generates a basic cobertura coverage (http://cobertura.sourceforge.net/xml/coverage-04.dtd) report providing detailed information on code coverage with line numbers. This coverage report is designed to be consumed by services like TFS, Jenkins. Please see example of XML generated by java : https://raw.githubusercontent.com/jenkinsci/cobertura-plugin/master/src/test/resources/hudson/plugins/cobertura/coverage-with-data.xml

To keep it simple, the `equal` matcher will only succeed if you compare apples to apples.

**Comparing NULLs is by default a success!**

To change the behavior of `NULL = NULL` comparison pass the `a_nulls_are_equal => false` to the `equal` matcher.

- Compound data can contain elements of any data-type. This includes blob, clob, object type, nested table, varray or even a nested-cursor within a cursor.

- Comparison of compound data is data-type aware. So a column `ID NUMBER` in a cursor is not the same as `ID VARCHAR2(100)`, even if they both hold the same numeric values.

When comparing compound data, utPLSQL will determine diff between expected and actual data.

The diff includes:

- differences in column names, column positions and column data-type for cursor data

- only data in columns/rows that differ

The diff aims to make it easier to identify what is not expected in the actual data.

Consider the following expected cursor data

| ID (NUMBER)| FIRST_NAME (VARCHAR2) | LAST_NAME (VARCHAR2) | SALARY (NUMBER) |

|:----------:|:----------------------:|:----------------------:|:---------------:|

| 1 | JACK | SPARROW | 10000 |

| 2 | LUKE | SKYWALKER | 1000 |

| 3 | TONY | STARK | 1000000 |

And the actual cursor data:

|~~GENDER (VARCHAR2)~~| FIRST_NAME (VARCHAR2) | LAST_NAME (VARCHAR2) | SALARY *(VARCHAR2)* | *ID* (NUMBER) |

|:-------------------:|:---------------------:|:--------------------:|:-------------------:|:-------------:|

| M | JACK | SPARROW | **25000** | 1 |

| M | TONY | STARK | 1000000 | 3 |

| **F** | **JESSICA** | **JONES** | **2345** | **4** |

| M | LUKE | SKYWALKER | 1000 | 2 |

When considering the data-sets as ordered, there are following following differences:

- column ID is misplaced (should be first column but is last)

- column SALARY has data-type VARCHAR2 but should be NUMBER

- column GENDER exists in actual but not in the expected (it ir an Extra column)

- data in column SALARY for row number 1 in actual is not matching expected

- row number 2 in actual (ID=3) is not matching expected

- row number 3 in actual (ID=4) is not matching expected

- row number 4 in actual (ID=2) is not expected in results (Extra row in actual)

utPLSQL will report all of the above differences in a readable format to help you identify what is not correct in compared data-set.

Below example illustrates, how utPLSQL will report such differences.

create or replace package test_cursor_compare as

--%suite

--%test

procedure do_test;

create or replace package body test_cursor_compare as

procedure do_test is

l_actual sys_refcursor;

open l_expected for

select 1 as ID, 'JACK' as FIRST_NAME, 'SPARROW' AS LAST_NAME, 10000 AS SALARY

from dual union all

select 2 as ID, 'LUKE' as FIRST_NAME, 'SKYWALKER' AS LAST_NAME, 1000 AS SALARY

from dual union all

select 3 as ID, 'TONY' as FIRST_NAME, 'STARK' AS LAST_NAME, 100000 AS SALARY

from dual;

open l_actual for

select 'M' AS GENDER, 'JACK' as FIRST_NAME, 'SPARROW' AS LAST_NAME, 1 as ID, '25000' AS SALARY

from dual union all

select 'M' AS GENDER, 'TONY' as FIRST_NAME, 'STARK' AS LAST_NAME, 3 as ID, '100000' AS SALARY

from dual union all

select 'F' AS GENDER, 'JESSICA' as FIRST_NAME, 'JONES' AS LAST_NAME, 4 as ID, '2345' AS SALARY

from dual union all

select 'M' AS GENDER, 'LUKE' as FIRST_NAME, 'SKYWALKER' AS LAST_NAME, 2 as ID, '1000' AS SALARY

from dual;

ut.expect(l_actual).to_equal(l_expected);

When the test package is executed using:

set serverout on

exec ut.run('test_cursor_compare');

We get the following report:

utPLSQL identifies and reports on columns:

- column misplacement

- column data-type mismatch

- extra/missing columns

When comparing rows utPLSQL:

- reports only mismatched columns, when rows match

- reports columns existing in both data-sets when whole row is not matching

- reports whole extra (not expected) row from actual, when actual has extra rows

- reports whole missing (expected) row from expected, when expected has extra rows

When comparing object type to object type or collection to collection, utPLSQL will check:

- if data-types match

- id data in the compared objects/collections are the same.

The diff functionality for objects and collections is similar to diff on cursors.

When diffing objects/collections however, utPLSQL will not check attribute names and data-types.

Below examples demonstrate how to compare object and collection data-types.

execute immediate 'delete from ut_compound_data_tmp';

execute immediate 'delete from ut_compound_data_diff_tmp';

gc_version constant varchar2(50) := 'v3.0.4.1640-develop';

grant execute on &&ut3_owner..ut_coverage_cobertura_reporter to public;

grant select, insert, delete on &&ut3_owner..ut_compound_data_tmp to public;

grant select, insert, delete on &&ut3_owner..ut_compound_data_diff_tmp to public;

create public synonym ut_coverage_cobertura_reporter for &&ut3_owner..ut_coverage_cobertura_reporter;

create public synonym ut_compound_data_tmp for &&ut3_owner..ut_compound_data_tmp;

create public synonym ut_compound_data_diff_tmp for &&ut3_owner..ut_compound_data_diff_tmp;

grant execute on &&ut3_owner..ut_coverage_cobertura_reporter to &ut3_user;

grant select, insert, delete on &&ut3_owner..ut_compound_data_tmp to &ut3_user;

grant select, insert, delete on &&ut3_owner..ut_compound_data_diff_tmp to &ut3_user;

create or replace synonym &ut3_user..ut_coverage_cobertura_reporter for &&ut3_owner..ut_coverage_cobertura_reporter;

create or replace synonym &ut3_user..ut_compound_data_tmp for &&ut3_owner..ut_cursor_data;

create or replace synonym &ut3_user..ut_compound_data_diff_tmp for &&ut3_owner..ut_compound_data_diff_tmp;

create global temporary table ut_compound_data_diff_tmp(

constraint ut_compound_data_diff_tmp_pk primary key(diff_id,item_no)