我们有两个不同的相同接口实现。将其视为参考和生产实施。这两个实现由不同的团队实现，目标是从两个实现中获得相同的结果。
创建参考实现的团队已经创建了大量基于Junit的测试用例（现在大约700个测试用例），并且这些单元测试在开发期间经常运行。我们可以针对生产实现运行相同的测试用例集。
通过回归测试来测试生产实现的功能。但是，如果能够针对生产实现运行单元测试，则可以快速反馈每次我们获得新版本的生产代码时是否出现严重问题。
但由于缺少生产版本中的某些功能，或者由于已知错误导致结果不同，因此并非所有测试都通过此实现。这使得很难及早发现回归。
这里有几个类别：
（A）仅对参考实施有意义且对生产实施不重要的测试用例
（B）测试生产实施时只需要省略某些断言的测试用例（即参考实施中报告的附加值）
（C）已知在生产实施中不起作用的测试用例，因为某些功能的开发滞后，但应该在以后加入
到目前为止，我们有以下选择：
使用if语句来混淆我们的代码，这些语句只包含在参考实现中有效的断言。这解决了（B）但很难维持。
使用assumeTrue。这对于（A）是可以的，但是给出了错误的印象，在（B）中一切正常。
我想拥有的是
能够基于像assumeTrue这样的运行时条件跳过某些测试，但是这些应该被报告为跳过而不是成功（C）
有更多的结果状态考虑到之前是否知道某个测试用例已经有效，那么
有没有人之前做过类似的事情，或者甚至可以使用JUnit（并且最好结合使用eclipse JUnit插件）？
答案 0 :(得分：1)
要跳过具有运行时条件的测试，可以使用Filter，您可以选择忽略测试，具体取决于基于测试方面的运行时条件（名称，更好的注释） @Development（）或@Version（）测试方法）。
要使用它来解决（B）你需要为每个版本使用不同的测试方法，一个用于3.1，一个用于3.2等。这看起来可能会使你的单元测试变得混乱，但实际上它使你的工作更容易挑选出适用于3.1的测试。
对于问题的“时间机器”部分，junit很难知道测试是否已经过去了。你需要在某处记录旧的结果。
要分析哪些测试已更改状态（从传递到失败），请通过CI系统以系统方式运行junit测试，然后将结果保存在可以进行后处理的位置，以便为您提供回归。例如，surefire xml报告很容易解析。
答案 1 :(得分：0)
我不知道你问题的第一部分，但就多个结果状态而言，你可能需要某种持续的整合。据我所知，JUnit无法“知道”您的测试用例过去是成功还是失败，因此您需要在其他地方获取此信息。
答案 2 :(得分：0)
您是否可以创建一个基类，其中包含已知在两种情况下都可用的所有测试用例，并使用包含特定于生产和参考实现的测试用例的其他两个类进行扩展？
如果它比那更细粒度（例如，测试很长并且其中90％在prod和reference中都有效）那么你可以采用相同的方法，但是在子类中放置重写方法不同的断言。 （你必须在基类中创建一些抽象方法来支持它）