Test data for development environment
Usually when we start working on a software system locally the database or other data storage will be empty. As we continue to work with our software we will end up with some useful data for manual testing over time, but often we need to reset or delete the data in order to work with multiple branches with incompatible schemas or other problematic changes.
One way to provide better developer experience is to have some test data ready to be used so that starting fresh doesn’t mean starting empty handed.
The simplest example of that would be recreating some default test user that a developer can use without having to register a new user account after starting the application. It is perhaps just a small time saver, but it can add up over time.
In a system I am working on right now we have a complex role based access control system and users can have different roles and belong to different teams. So now, instead of creating just one user we can recreate users for all different roles that are ready to be used right away. As features often vary for different roles, having predefined users is a big time saver.
The datasets that we provide for use in a development environment can be handy in many occasions and there are really no limits in how complex and sophisticated they can be:
Weird, atypical data to test UI rendering in edge cases
Huge datasets for testing performance
Time series data when we need to have some data from the past but are hard to recreate immediately
Data simulating interactions of multiple users
Data for a particular feature that demostrate its use
and so on
Such test data can be:
Recreated automatically if they don’t exist when starting an application (useful for data like user accounts that we want to have available almost all the time)
Setup through a command in an entrypoint of a software system for when we want test data for a particular use case
I think there is a huge benefit in providing some common datasets to everyone that are easily accessible and perhaps just a command away in a development environment.
We should also think about making it easy to create custom test datasets for developers and encourage them to do so. Any system that has application level import and export, even if private, is a good start. Some frameworks like Django provide a system to do just that in a way that makes it easy to create a snapshot of the current state and load it again with minimum amount of code.
Some applications have starter templates for end users which is not only a great thing for them, but can also serve as a starting point when our development data stores are empty.
All in all I think that caring about test data for development environments can go a long way to increase productivity and lower frustrations from repetitive tasks.
—
Petr