Hey, when using your library in our code, we've found the need to _NOT_ call the updateBlock when the application is started from a fresh install. In fact, we've had to code defensively around this case.
I have since forked your code and created a private pod, but thought that this change might be something that you would want.
Being a good citizen I've written unit tests around the new method. I found it difficult to mock/change the application version and build numbers as need for my test. So I used a technique called method swizzling to properly mock out these values. See it at the bottom of the unit test class.
In addition I added an example test method to show case how much more powerful these tests can be instead of relying on the test project's bundle values. Seemed pretty important as MTMigration core is built around these bundle values.
I hope this all makes sense. Let me know what you think.
Hey, when using your library in our code, we've found the need to _NOT_ call the
updateBlock
when the application is started from a fresh install. In fact, we've had to code defensively around this case.I have since forked your code and created a private pod, but thought that this change might be something that you would want.
Being a good citizen I've written unit tests around the new method. I found it difficult to mock/change the application version and build numbers as need for my test. So I used a technique called method swizzling to properly mock out these values. See it at the bottom of the unit test class.
In addition I added an example test method to show case how much more powerful these tests can be instead of relying on the test project's bundle values. Seemed pretty important as
MTMigration
core is built around these bundle values.I hope this all makes sense. Let me know what you think.
Thanks for the pod, very helpful otherwise.