Why not use generic ADO.NET/JDBC interfaces?

Although database interfaces in .NET and Java are in theory database-independent, several key differences in SQL syntax and in driver implementation make it virtually impossible to support effective testing with a completely generic approach. The main differences are:

1. Reading table columns and mapping their datatypes to host types
2. Reading stored procedure/function parameters and mapping datatypes to host types
3. Extracting parameter names from ad-hoc SQL queries
4. Building plumbing SQL commands like insert/returning primary key
5. Instantiating objects such as DB connection, commands, or parameters

To be useful, DbFit needs to provide access to vendor-specific features as well as to generic features, so the database-connectivity layer had to be abstracted one level more.

Previous page: Installing DbFit Next page: Connecting to the database Parent page: DbFit for Integration tests