A GenRocket Philosophy For Data Generation by Gregg Bolinger on Mar 03, 2014

At the end of this month, I’m going to have the opportunity to present GenRocket to my local tech group. I was asked to provide a title for my talk and a small description. While I pondered that, I tried to think of what really sets GenRocket apart from other means of data generation. As I let my mind run in many different directions and several tangents, I kept coming back to something that really wasn’t GenRocket specific, although, something that it excels at. It isn’t a specific feature. It is something that our CEO has been referring to as a GenRocket Philosophy. Most people still think about data generation in terms of databases. I’ve written before about GenRocket’s ability to think outside of the database. One of our clients came to us in the middle of a project with no real tests and no test data. They needed GenRocket to solve two main problems:

  • GenRocket should generate enough test data to get them to 100% code coverage.
  • GenRocket should seed the platform with enough data so they can demo to potential customers.


Athough GenRocket can do it very well, populating a database with the appropriate data wasn’t really enough to solve these problems. And this is where the philosophy comes in. We made the decision to utilize their existing service layer. GenRocket’s job was to generate only the data necessary for the services to do their job. The first part of the philosophy is that the business logic should remain within the source code of the application when possible, rather than within GenRocket. As Software Engineers, we’re writing code that contains business logic. A lot of times this is built around data input. Data comes in, it is processed, and then stored. Don’t get me wrong, modeling business logic in GenRocket is a completely valid approach and something we’re proud to say that GenRocket is capable of. The key is to know when to utilize that ability and when to put that burden elsewhere. The second part of the philosophy is that we decided to use XML files as a means of data transport rather than a final destination. A lot of times we need to generate data using a Receiver for a very specific purpose. XML or JSON files for web services. CSV files for feed engines. Other times, the generated data is created in a temporary format that is meant for consumption and transformation. The solution was to generate the XML files and write these small chunks of code called loaders. These loaders read the XML and executed the service methods passing in the required data. What did this accomplish? Everything!

  • We limited the amount of test data needed since the data wasn’t just dumped straight into a database
  • By utilizing existing services and business logic, the system was seeded with demo data using it’s own code which,
  • Revealed existing bugs in the system and
  • Provided a simple patterned approach to generating data to fully test their platform.

One of the things I love about GenRocket is its ability to adapt without changing. I’m sure that there are a dozen ways to solve the problem I described in this article. I’m also certain that GenRocket could have been used for every one of them. Sometimes, it comes down to features. Other times, it comes down to philosophy. I’m excited that GenRocket’s feature set allows for just about any philosophy when it comes to generating data.