Database applications are very common and there has been much attention to testing them and the individual database management systems with which they interact. Yet, there has been very little work devoted to testing arguably the most important artifact involving an application supported by a relational database — the underlying schema! The development of a database schema is a process open to flaws like any stage of application development. Examples of potential flaws in database schemas include incomplete primary keys, incorrect foreign keys, and omissions of
NOT NULL declarations. The schema’s cornerstone nature to a database application means that defects need to be found early in order to prevent knock-on effects to other parts of an application and the spiralling bug-fixing costs that may be incurred.
In this important area of testing for relational database schemas, there are many challenges that researchers and developers need to address. Some recent advances in this field have focused on automatically generating test data to exercise the constraints in the database schema and assessing the effectiveness of the generated data through the use of mutation analysis.
The paper (Kapfhammer, McMinn, and Wright 2013)
Of course, the process of automatically generating test data raises the question “well, how good is this data?” The paper (Wright, Kapfhammer, and McMinn 2013)
Interested in learning more about this topic? Since this blog post was first written, my colleagues and students and I have published several additional papers about the testing of relational database schemas, with noteworthy ones being (McMinn, Wright, and Kapfhammer 2015)