3

I'm building a web application in Spring. I'm using an in-memory (embedded) database for my integration test - HSQL My production database is MySQL.

When i setup my integration tests a while back i took a SQL dump from production db and converted that to HSQL (DDL & inserts).

Now, my production database is going through an evolution of constant on-going change (the schema is constantly been updated with new functionalities from new business requirements)

How can i ensure my HSQL in-memory integration test DB is up to date with my Production?

  • 4
    For something as fundamental as a schema change, wouldn't you want to do the change on your test instance first so you can verify the app still works before potentially breaking production? – Ixrec Nov 12 '15 at 23:35
  • Yes i would ideally. But our company's development process is all focused on production. We don't even have any tests at all (that incl. Unit). And it is my job to introduce these tests into their dev process. Unfortunately i can't tell them to stop and wait for my tests to catch up or switch the process around. – SoftwareDeveloper Nov 12 '15 at 23:38
  • 1
    Perhaps you could ease them into it by doing the change to test and prod at the same time for now? Though this aspect of the question might be better suited for a chat discussion. – Ixrec Nov 12 '15 at 23:39
  • thanks. perhaps you're right. probably that's the best approach after all - is to make changes on both at same time or start changing the test db first before applying same change on production. – SoftwareDeveloper Nov 12 '15 at 23:42
  • 1
    In order for this to work, you're going to have to insist that changes are tested first. If you don't have that power, you'll need to go through the person who tasked you with this. If they're really interested in having tests, then they'll make this happen. Otherwise... Brush up your resume. – RubberDuck Nov 12 '15 at 23:52
4

Well, you wrote

When i setup my integration tests a while back i took a SQL dump from production db and converted that to HSQL (DDL & inserts).

so automate this process - build some scripts or program which does what you did with as few manual steps as possible, then you can repeat the process of updating your test database much easier and as often as needed.

Side note to the commenters: Having the schema change first in production, and updating the OP's application afterwards can make perfectly sense if the application is not a production-critical part of an enterprise system. For example, an application which is used to make some data analysis on a production database at the end of a defined period like a quarter or a year. Under given time constraints, it does not make sense to stop the development/deployment of production critical apps, and wait until every minor important analysis tool was tested against the new schema.

(Don't get me wrong, I hope for your production critical apps there is something like a test database, and your colleagues test those applications first in that environment before deploying into production).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.