The document discusses testing the database layer in a smarter way than usual. It proposes using multiple databases for development, QA, and production environments. The best practice is to initialize test data, call the API, compare the actual database data to the expected data from a file. This can be done using the DBUnit framework which provides components for connecting to a database, representing test data sets, and performing database operations for testing purposes.
Report
Share
Report
Share
1 of 21
More Related Content
Testing database content with DBUnit. My experience.
1. Can you test database layer more
smart than usual?
Serhii Kartashov
December 2012
SoftServe
2. Agenda
What’s a problem?
How we want to resolve that?
Are you professional?
3. Agenda
What’s a problem?
How we want to resolve that?
Are you professional?
4. Problem
Task:
please remove old and didn’t marked data from
production!
The problem is this:
you have a SQL database, some stored procedures,
and a layer of code sitting between your application
and the database. How can you put tests in place to
make sure your code really is reading and writing the
right data from the database?
5. What’s the best practice? You need
[multiple] databases!
devQA (local) prodQA production
MySQL
SQL Oracle
Aster
MySQL
Oracle
Aster
MySQL
Oracle
Aster
6. How I wanted to do that? First step:
initialization test data.
object file network
con.
Prepare the
data
SQL commit
13. DBUnit Core Components
• IDatabaseConnection - interface representing a DbUnit
connection to a DB
• IDataSet - interface representing a collection of tables
• DatabaseOperation - abstract class representing an operation
performed on the database before and after each test.
Operations:
• NONE
• UPDATE
• INSERT
• REFRESH
• DELETE
• DELETE_ALL
• TRUNCATE_TABLE
• CLEAN_INSERT (DELETE_ALL and INSERT)