3 ms·

Ask HN: Best practice for test and production environments for your company

12 points by jollychang 11y ago

Is there production/Testing environments for your company? How to seed the database and redis for testing environment？

kat 11y ago
In general, it depends on what type of testing and what technologies you are using. For performance testing and other testing that requires large data sets, I prefer to have a "golden" copy of a database that is simply restored to the testing environment as needed. For smaller integration tests the database is usually seeded dynamically, I've seen it done through fixtures/bootstrapping (Django, Grails, and other frameworks support this) or through SDK calls in custom code (using your own code base to populate the database). Are you also trying to seed your production environment?
- jollychang 11y ago
  we are only seed for testing environment.
davismwfl 11y ago
I like to seed testing databases as follows: * Take all data that caused a failure in the application and have a script that generates that in the test database. Maybe it is a unicode character that was misinterpreted etc. This makes a basic regression test easier to apply. * Take some percentage of the Production database and have a script or application obscure the data and load it into the test environment. Generally I like to make this configurable so it can be used to generate a small dataset on a devs laptop, or a larger dataset on a test server. * Obscure the data differently every time the application runs, and have the data stay within the same range as the original production data. For example, if a currency field showed $199.00, then you might obscure it to be $179.00, use a formula to do this. If a string contained 4 spaces, 2 capitals and 3 punctuation marks keep the ratios the same just obscure the character values (I do not obscure punctuation for testing). I point out the obscuring because it is the easiest way to help prevent client data from being lost, stolen or abused. I like to write an application that copies the data over and lets you pick how much data to use. For example, for a dev laptop, maybe they can only get 1% or 10k complete records. For testing server it can get anything from 20% to 100%. Also, if you do it this way, you can have a developer database generated every day overnight so it is ready for anyone who needs to just copy it local in the morning for test, and for the test server you can regenerate it on some rolling basis to keep it fresh. Also, have the application reseed the cache from the newly generated test database.

12 points by jollychang 11y ago

Is there production/Testing environments for your company? How to seed the database and redis for testing environment？

kat 11y ago

In general, it depends on what type of testing and what technologies you are using. For performance testing and other testing that requires large data sets, I prefer to have a "golden" copy of a database that is simply restored to the testing environment as needed. For smaller integration tests the database is usually seeded dynamically, I've seen it done through fixtures/bootstrapping (Django, Grails, and other frameworks support this) or through SDK calls in custom code (using your own code base to populate the database). Are you also trying to seed your production environment?

jollychang 11y ago
we are only seed for testing environment.

davismwfl 11y ago

I like to seed testing databases as follows: * Take all data that caused a failure in the application and have a script that generates that in the test database. Maybe it is a unicode character that was misinterpreted etc. This makes a basic regression test easier to apply. * Take some percentage of the Production database and have a script or application obscure the data and load it into the test environment. Generally I like to make this configurable so it can be used to generate a small dataset on a devs laptop, or a larger dataset on a test server. * Obscure the data differently every time the application runs, and have the data stay within the same range as the original production data. For example, if a currency field showed $199.00, then you might obscure it to be $179.00, use a formula to do this. If a string contained 4 spaces, 2 capitals and 3 punctuation marks keep the ratios the same just obscure the character values (I do not obscure punctuation for testing). I point out the obscuring because it is the easiest way to help prevent client data from being lost, stolen or abused. I like to write an application that copies the data over and lets you pick how much data to use. For example, for a dev laptop, maybe they can only get 1% or 10k complete records. For testing server it can get anything from 20% to 100%. Also, if you do it this way, you can have a developer database generated every day overnight so it is ready for anyone who needs to just copy it local in the morning for test, and for the test server you can regenerate it on some rolling basis to keep it fresh. Also, have the application reseed the cache from the newly generated test database.