Unit testing migrations #486
-
Hi there! I'm using Mongock 4 in my application. And I've developed about 50 migrations over the last year. I'd like to start writing unit tests for the migrations I write going forward. Is there some documentation or blog article that describes how I can write a unit test that seeds some test data into a mongo instance, and then runs the migration under test, then confirms that the new data is as expected? Perhaps the test might need to startup a mongo in an embedded mode. Perhaps using testcontainers.org. Much appreciated! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Hello, well, if you are speaking about unit tests, you probably want to call you ChangeLog classes(ChangeUnits in version5), injecting mocks as parameter and verify they are called with the right parameters the amount of time expected. If we are speaking about integrations tests, I highly recommend using testcontainers, which is not an embedded database, just a real database running in a container during the tests and then is destroyed. The problem with testcontainers is that you probably want to start fresh in every test, which testcontainer does by default, but, as you may guess, that will make the execution time too long for you tests. That's ideal, because you don't need to worry about cleaning the database. If the execution takes too long, you have two options: start and stop the container in every test or, which I have found a bit more practical, is using the same container(server), but different database in each test, or even just pointing to as different changeLog collection in every test. I hope it's helpful. PD: We are about to deploy our website, where we'll post technical blogs, this may be one of the first ones, but I cannot tell you when this will be available. |
Beta Was this translation helpful? Give feedback.
Hello,
well, if you are speaking about unit tests, you probably want to call you ChangeLog classes(ChangeUnits in version5), injecting mocks as parameter and verify they are called with the right parameters the amount of time expected.
If we are speaking about integrations tests, I highly recommend using testcontainers, which is not an embedded database, just a real database running in a container during the tests and then is destroyed.
The problem with testcontainers is that you probably want to start fresh in every test, which testcontainer does by default, but, as you may guess, that will make the execution time too long for you tests. That's ideal, because you don't need to worry abou…