Comments on: Using an empty database (learn from your mistakes) http://blog.wl0.org/2009/07/using-an-empty-database-learn-from-your-mistakes/ Random thoughts on different topics Fri, 27 Jan 2012 06:02:03 +0000 hourly 1 http://wordpress.org/?v=3.1.3 By: KB http://blog.wl0.org/2009/07/using-an-empty-database-learn-from-your-mistakes/comment-page-1/#comment-9400 KB Sun, 15 Jan 2012 07:06:24 +0000 http://blog.wl0.org/?p=100#comment-9400 Hi Simon. I know it's been a while since you originally posted this but where I work, we call what you have described as a reference data set (RDS). The goal of the RDS is to provide just enough structure and data to allow an application to run cleanly. A RDS usually contains primarily DDL. The neat thing with a RDS is it can be "played" over and over during testing. Take that a step further and add data designed to specifically test a feature or known bug that is meant to be played after installing the RDS and now you have a test fixture. This makes it no only possible, but terribly simple to simulate problematic data without putting your code into production. Another huge win you get out of these tools together is the ease of tracking them in source control. Now, your application code and data repository code can all be stored together. Finally, this also makes it much simpler to automate application testing and verification because it gives you an easy way to repeatably reset your data store to a known consistent state. As you can see, combining reference data sets with test fixtures can help developers proceed with greater confidence that the application interacts well with the data store, no matter what kind of store is used because developers can quickly get to a known state and easily verify that the application and data store perform as expected after making a change. KB Hi Simon. I know it’s been a while since you originally posted this but where I work, we call what you have described as a reference data set (RDS). The goal of the RDS is to provide just enough structure and data to allow an application to run cleanly. A RDS usually contains primarily DDL. The neat thing with a RDS is it can be “played” over and over during testing.

Take that a step further and add data designed to specifically test a feature or known bug that is meant to be played after installing the RDS and now you have a test fixture. This makes it no only possible, but terribly simple to simulate problematic data without putting your code into production.

Another huge win you get out of these tools together is the ease of tracking them in source control. Now, your application code and data repository code can all be stored together.

Finally, this also makes it much simpler to automate application testing and verification because it gives you an easy way to repeatably reset your data store to a known consistent state.

As you can see, combining reference data sets with test fixtures can help developers proceed with greater confidence that the application interacts well with the data store, no matter what kind of store is used because developers can quickly get to a known state and easily verify that the application and data store perform as expected after making a change.

KB

]]>