Unitils

PATCH: DbUnit module does not compare empty tables

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.2
  • Fix Version/s: 2.3
  • Component/s: dbunit
  • Description:
    Hide
    If an @ExpectDataset has an empty table, that table is not compared by DbUnitAssert, which could cause the test case to pass in situations where it should fail (for instance, if you are testing a method that deleted the only row in a table). I'm providing a patch, with a test case that shows the problem.
    Show
    If an @ExpectDataset has an empty table, that table is not compared by DbUnitAssert, which could cause the test case to pass in situations where it should fail (for instance, if you are testing a method that deleted the only row in a table). I'm providing a patch, with a test case that shows the problem.
  1. UNI-123.patch
    (3 kB)
    Felipe Leme
    12/Apr/09 5:46 AM

Activity

Hide
Felipe Leme added a comment - 12/Apr/09 5:50 AM
BTW, I faced this problem while working in the Unitils example for the upcoming JUnit in Action 2nd edition book (http://manning.com/tahchiev/). It would be very nice if this patch is applied (or the problem fixed in some other way) soon, otherwise I will have to hack the examples to work around this issue.
Show
Felipe Leme added a comment - 12/Apr/09 5:50 AM BTW, I faced this problem while working in the Unitils example for the upcoming JUnit in Action 2nd edition book (http://manning.com/tahchiev/). It would be very nice if this patch is applied (or the problem fixed in some other way) soon, otherwise I will have to hack the examples to work around this issue.
Hide
Tim Ducheyne added a comment - 26/Apr/09 2:44 PM
Hi Felipe,

I found our original implementation of the expected data set not satisfactory, so I built a new one.
Following improvements are added:

* as you requested: if you add an empty table to the expected data set, the assertion will fail if the actual table is not empty

* better dealing with different types of values: comparing 1.00 with 1 or comparing dates used to give problems this is fixed now

* the comparison now also takes primary key columns into account: if you specify a pk value in the expected data set, this row will now be compared with the corresponding actual row with those primary key values.

* better output. The best matching differences are search and the actual content of the tables is added.
Example output:

java.lang.AssertionError: Assertion failed. Differences found between the expected data set and actual database content.
Found differences for table PUBLIC.TEST:

  Different row:
  pk, column1, column2
  "1", "value1", "xxxx"

  Best matching differences:
  column2: "xxxx" <-> "value2"


Actual database content:

PUBLIC.TEST
  COLUMN1, COLUMN2
  "value1", "value2"
  "value2", "value3"


Other example output:

java.lang.AssertionError: Assertion failed. Differences found between the expected data set and actual database content.
Expected table to be empty but found rows for table PUBLIC.TEST


Actual database content:

PUBLIC.TEST
  COLUMN1, COLUMN2
  "value1", "value2"
  "value2", "value3"


Still todo:
* make the date format configurable
* add special values like current_date
* create @NotExpectedDataSet


Could you please take a look? Remarks and suggestions are very welcome.

best regards,
Tim
Show
Tim Ducheyne added a comment - 26/Apr/09 2:44 PM Hi Felipe, I found our original implementation of the expected data set not satisfactory, so I built a new one. Following improvements are added: * as you requested: if you add an empty table to the expected data set, the assertion will fail if the actual table is not empty * better dealing with different types of values: comparing 1.00 with 1 or comparing dates used to give problems this is fixed now * the comparison now also takes primary key columns into account: if you specify a pk value in the expected data set, this row will now be compared with the corresponding actual row with those primary key values. * better output. The best matching differences are search and the actual content of the tables is added. Example output: java.lang.AssertionError: Assertion failed. Differences found between the expected data set and actual database content. Found differences for table PUBLIC.TEST:   Different row:   pk, column1, column2   "1", "value1", "xxxx"   Best matching differences:   column2: "xxxx" <-> "value2" Actual database content: PUBLIC.TEST   COLUMN1, COLUMN2   "value1", "value2"   "value2", "value3" Other example output: java.lang.AssertionError: Assertion failed. Differences found between the expected data set and actual database content. Expected table to be empty but found rows for table PUBLIC.TEST Actual database content: PUBLIC.TEST   COLUMN1, COLUMN2   "value1", "value2"   "value2", "value3" Still todo: * make the date format configurable * add special values like current_date * create @NotExpectedDataSet Could you please take a look? Remarks and suggestions are very welcome. best regards, Tim

People

Dates

  • Created:
    12/Apr/09 5:44 AM
    Updated:
    27/May/09 8:27 PM
    Resolved:
    26/Apr/09 2:44 PM