fitnesse does not have a excel reader out of the box. you can copy the data into a fitnesse page and then use spreadsheet to fitnesse to quickly convert it into a fitnesse table, then dbfit can manage it. Otherwise, you can write an excel file reading fixture yourself and then have that processed at runtime.

Using dbfit can I read data from multiple columns from Excel sheet and create a table and insert the data read from excel in to the created table.

Thanks
Tak

Back to the main topic. I don’t have unit tests, but I’ve started to keep a library of code examples, and some of those examples are queries that expose bad data.

utPLSQL is a great tool as far as I am concerned, but it was not good enough to convince DB developers to change the way they worked. I think that the problem is exactly in all the boilerplate code – to do these three simple assertions you would have to declare the package spec, package body, function etc… because concatenatetrings is a stored proc with output parameter, not a function, this adds three other boilerplate lines to call the proc separately from the assertion, and another line to declare the variable to store that output parameter. DbFit does all that boiledplate code automatically and allows DB developers to focus on assertions.

You say it would take 20 lines to check 3 concatenations work correctly. If I ignore the boilerplate code, in utPLSQL this looks like this, which is not a million miles from the equivalent in JUnit:

utAssert.eq(‘Concatenation 1′, ConcatenateStrings(‘Hello’, ‘World’), ‘Hello World’);
utAssert.eq(‘Concatenation 2′, ConcatenateStrings(‘Arthur’, ‘Dent’), ‘Arthur Dent’);
utAssert.eq(‘Concatenation 3′, ConcatenateStrings(‘Ford’, ‘Prefect’), ‘Ford Prefect’);

…and if you were doing more assertions, you’d extract that repeated line into a procedure.