Question

I need to use a third party .jar lib in my application: unfortunately the way this third party app is set up makes it well nigh on impossible to test on my windows box (since it’s set up for a unix environment – I’ll spare the details). So I have refactored it to be able to test it (altered the structure to use maven/spring so the handling of property files is more flexible, without changing the call out interface). If the new version compiles to the same .jar name/version/etc. I can presumably test it locally and then compile in the “real” .jar for production. Is this is daft idea? (I have a strong hunch that it is, since I am introducing a non-trivial dependency…). If so, how can I better test this library (without e.g. having to merge my own refactoring changes into the original code)?

Answer 1

Conceptually you have subdivided the third-party jar into two – the property bit and the rest. You replace the property bit with your own stuff and then procede to test the rest. On release you prepare a package including the bit you have tested and the original property stuff which you have not. In taking this approach, what risks have you introduced?

1. That the code you release will not be the code you tested – it’s a different JAR, albeit with careful process not a very different JAR – so if you trust yourself to get it right this may be an acceptable risk.
2. That the code you didn’t test is broken. This suggests that at least some testing is needed on the real platform.
3. That the tests on Windows give different results from tests on Unix. Again some degree of Unix testing is indicated.

I think that your appraoch is pragmatic and that the risks can be mitigated by having at least some tests be executable on Unix. I assume that your Windows-based testing is for ease of development/debugging. I would do this, but I would try to build a regression test suite that I can run on Unix – JUnit tests could run there.