Tests need test fixtures. Many books and blogs have been written on proper test fixture management, but when it comes to testing database changes, best-practices often leave you saying “is that all I can really do?”

Most testing pros recommend creating test fixtures via version-controlled scripts so you know where your data came from. This is often a good idea, but can be challenging in practice because recreating the breadth of production data with a script is hard (perhaps this is why we’ve all seen a test User table with 3 entries–“Test”, “Jane Doe” and “fasdfasdfa”). Additionally, each time you want to run a test, you need to run that script, produce your data and load it into a database. This can be time consuming and slow your testing down.

With FlockerHub and Fli, you can snapshot real databases, richly populated with pernicious (i.e. real-world) data that a programmer won’t think up on their own, and use these as your test fixtures. These data volumes can be distributed via FlockerHub to any access-controlled user, and updates to the Docker volumes (for example, a nightly update) are fast, since Fli only pushes and pulls changes (or diffs) since a previous snapshot.

Problems with testing today:

  • Impossible to create prod-like data with a script
  • Even with scripts, slow data ETL operations
  • Can’t publish data fixtures for easy access by others
  • Prod snapshots can’t be version controlled
The full complexity of your data, simply

The full complexity of your data, simply

You could write scripts to generate realistic test data. But getting it right is extremely difficult. It is hard to predict the crazy things your users will do with your app once you ship it, so predicting your data is like staring into a crystal ball.

Instead of guessing, use realistic data for testing. Using Fli to snapshot your databases, and FlockerHub for volume storage, you can use your actual data, or realistic test harnesses, as part of your everyday testing procedures. You can always do data-masking before putting your data into FlockerHub if you need obfuscation for security.

Data volume snapshots, without giving up version control

One of the big advantages to the script method of test fixture generation is that you can version-control your scripts so you always know where your data came from and how to recreate it. You don’t want to lose that benefit.

With FlockerHub and Fli, you don’t have to. Every snapshot has a complete list of metadata fields that let you identify the who, what, when and where of your data. And because the data is version controlled, even if your data has changed a lot, you can always roll back to a previous version.

Data volume snapshots, without giving up version control

Write a microservice. Publish a test fixture.

As teams move to microservices, the importance of integration testing increases. As a microservice author, you need to make sure your stuff works with other services, and these other services need to make sure they work with yours.

FlockerHub lets you publish your test fixtures to a centralized, version controlled repository that any of your colleagues can access locally or on their test infrastructure, making integration tests easier.

Signup for FlockerHub today

Learn more about FlockerHub and Fli

Push and pull data snapshots

The basics of how to move data with Fli and FlockerHub.

Creating volumes

Learn how to create a data volume using Fli, the FlockerHub CLI.

Updating object metadata

Learn how tag your data snapshots with user-defined attributes so they are easy to find and manage.

How to setup Fli with your ZPool

Learn how to set up a local storage pool to store and take snapshots.

Got a question?

Thanks for your email, we'll be in touch shortly