我们有一个为较老的Java VM（特别是1.3 ME）编写并运行的库。使用在较新VM下运行的测试工具测试针对较旧Java VM的代码
它会产生不准确的结果，使用'现代'测试工具，运行在1.6 VM下测试库的功能？从库到VM之间不同（例如IO）类
呼叫被抽象的，所以测试工具可以提供自己支撑实现。从理论上讲，我们可以独立于它所运行的平台来测试应用程序逻辑。
这个模型是否存在特定的区域，或者不同的虚拟机可能导致测试结果错误？显然，在测试库时能够使用类似泛型和现代测试工具的东西具有巨大优势，但如果测试无效，这些将被否定。
要解释这样做的原因：我们正在编写的代码与特定的虚拟机（例如，Blackberry和Android手机。）设备的工作原理，所以我们开发和代码的公共API在可能的情况。我们可以编写一个合理的Java共享子集，但是当涉及到测试时，在我们可以访问虚拟机的桌面上运行业务逻辑，这些虚拟机提供了更好的测试工具（例如EasyMock等框架）。
我不认为我会建议在远不同的环境中进行测试。不过，这里有一个替代解决方案。使用Java 1.6编写测试工具并使用Retroweaver使其与1.3兼容。然后在1.3上运行测试环境，就像在现实世界中使用它一样。你将能够使用泛型和现代化的图书馆。但是，您将无法使用Java运行时超过1.3版的功能。这可能是一个合理的妥协方案，允许测试相同的环境，因为图书馆将被用于。
可能。
我假设编译时库是1.3 JVM（不只是类的版本目标）。否则，你可能会遇到方法/类/字段未找到的错误等。
如果某些代码已写入实现而不是抽象，则可能会出现错误。也就是说，开发人员依靠观察到的行为（“我试过并且它工作了”）而不是1.3文档中记录的内容。
较旧的运行时可能会显示不存在于较新的错误中的错误。可能有解决方法，但是在新的运行时中将不会检测到问题。
我认为（在技术上）单元测试Java类的应用程序逻辑会被罚款上较新的VM，正如你说的，语言的好处将使它更容易些。
虽然我不得不说我认为编写已经编译好的类的测试有点奇怪。假设你发现错误，你将不得不在1.3上修复它们，这可能会让开发人员不断地从1.6版的JUnit测试和1.3版的代码中交换出来。
这听起来像你真正想要在这种情况下，做一些集成测试，证明了老班会仍然在他们的旧的VM上运行。如果是我，我会为了简单而保留所有内容 - 但这取决于测试类的目的。如果有一天你打算迁移到1.6，那么从长远来看，新型测试会更好。
对不起！最终没有多少结论性的答案！ :)
这是一个很好的建议，值得调查。很难为这个问题指定一个“正确的”答案，但是这肯定会解决这个问题。 – AndyT 2011-04-27 10:08:40