Testing code targeted at older Java VM with a test harness running under newer VM

We have a library written for (and running on) an older java VM, specifically 1.3 ME.

Will it produce inaccurate results to use a 'modern' test harness, running under a 1.6 VM to test the functionality of the library?

Calls from the library to classes that differ between VMs (such as IO) are abstracted, so the test harness can provide its own supporting implementations. Theoretically then, we can test the application logi开发者_如何学Pythonc independently of the platform that it is running on.

Are there specific areas where this model breaks down, or where the different VMs might cause false results from testing? Obviously there are huge advantages to be able to use things like generics and modern test harnesses when testing the library, but these would be negated if the tests are not valid.

To explain the reason for this: we are writing code that works on devices with specific VMs (eg. Blackberry and Android phones), so we develop and code to common APIs where possible. We can code to a reasonable shared subset of Java, but when it comes to testing, run the business logic on our desktops where we have access to VMs that provide better facilities for robust testing (eg. frameworks such as EasyMock etc.).

I don't think I'd recommend testing in an environment that far different. Here's an alternative solution for you though. Write your test harness with Java 1.6 and use Retroweaver to make it 1.3 compatible. Then run your test environment on 1.3 like it'll be used in the real world. You'll be able to use generics and modern libraries. You won't be able to use features from the Java runtime beyond 1.3 however. That's perhaps a reasonable compromise to allow testing the same environment as the library will be used in.

Possibly.

I'm assuming the compile-time library is the 1.3 JVM (not just the class version target). Otherwise, you can end up with method/class/field-not-found errors and the like.

If some of the code has been written to the implementation and not the abstraction, you may get bugs. That is, the developer is relying on observed behaviour ("I tried it and it worked") and not what has been documented in the 1.3 documentation.

The older runtime may exhibit bugs that are not present in the newer one. There may be workarounds, but the problem will not be detected on the new runtime.

I think (technically) unit-testing your application logic of java classes will be fine on a newer VM and, as you say, the language benefits will make this easier.

Although i have to say i think it's a little strange to be writing tests for classes that have already been compiled. Presumably if you find errors you'll have to fix them on 1.3 as well which may be annoying for developers constantly swapping from JUnit tests on 1.6 and code on 1.3.

It sounds like what you really want to do in this case is some integration testing, proving that the old classes will still run on their old VM. If it were me i'd keep everything on 1.3 for simplicity - but it really depends on the purpose of the test classes. If one day you intend to migrate to 1.6 then newer-style tests would be better in the long run.

Sorry! Not much of a conclusive answer in the end! :)