在用户界面上执行变异测试是一种良好的做法吗？
我和我的队友很难理解是否可以/应该对涉及Swing类的JUnit测试进行突变测试。
更准确地说，我们目前正在使用Junit 4和Assertj Swing来测试接口，以完成大学的测试任务（使用TDD）。我们还使用PITEST作为突变测试框架。
我们使用WindowBuilder插件为Eclipse构建Swing类，因此我们对类的结构没有太多控制。单元测试都是绿色的，但当运行pit时，这些类中的pit抛出了大量异常，测试失败得很惨。你可以在travis上看到maven日志。
由于我们才刚刚开始了解测试世界，因此，如果有人能提出建议，真正处理这些事情，我们将不胜感激。
非常感谢你。
共有1个答案
突变测试用于测试测试覆盖率，而不是测试代码。因此，当您的测试失败时，一切正常，您的测试覆盖率也可以接受。
问题是UI测试很难编码，也不太稳定（至少几年前是这样，尤其是Linux）。所以突变测试没有为它们提供额外的价值。UI代码中的任何微小变化都可能提供无法解释的堆栈跟踪，所以你不能说你的测试是好的还是Swing太复杂了，可以很容易地得到（Swing抛出大量异常，所以任何微小的变化都可能引发其中一个）。
我的建议是标准的：将您的UI代码与业务逻辑分开，并为您的业务类提供正常测试。在这种情况下，您的突变测试可能是合理的。
-
在Android上，有两种可能的方式通过广播接收器收听系统事件： 静态地，通过清单 由于一些项目包含大量活动、服务和“管理器”类，因此使用一个BroadcastReceiver通知应用程序上的所有侦听器所发生的事情，而不是使用多个BroadcastReceiver（以及它们的代码处理），可能会很有用。 这种广播接收器的一个示例是侦听连接更改的接收器： 目的是在应用程序处于活动状态时（通过服务和/或
-
问题内容： 过去，我使用以下方法读取大量代码： 这样做是惯例吗？ 优点和缺点是什么？ 在我看来，这就像完成异常的“ Agent Orange”方式 编辑 处理方法中的预期异常 引发意外异常（一对一） 不在乎错误 那是路要走吗？ 问题答案： 你不应该扔。这就是为什么。 Throwable是可抛出的事物层次结构的顶部，由and组成。由于根据定义是由不可挽救的条件引起的，因此将它们包括在方法声明中是没有
-
我见过很多次scala代码使用Option（对于简单值）或[List[Error]，T]来处理错误。 这为这样的代码提供了位置 这会产生一个不太好的代码嵌套，迫使您处理每一步的失败，并迫使您让所有函数返回一个[...] 所以我想知道 > 在scala（或一般的函数式编程）中不鼓励使用异常 使用它们有任何缺点（关于不可变性或代码并发性） 异常与原理或函数式编程有些冲突 你可以想出一个更好的方法来编写
-
例如，如果我想将设置为数组中不等于0的第一个元素，我可以编写： 这是不好的做法吗？ 此外，希望这是一个足够基本的场景，不要太固执己见。
-
我有一个IntentService，它使用TimerTask每隔45秒在OnHandleContent中调用webservice。 我的问题是：我正在调用应用程序启动IntentService，而在OnHandleIntent中，由于TimerTask，任务不断重复。。这样做是一种好做法还是有任何缺点？我应该在我的活动中使用报警管理器每次调用intent service，还是继续使用timer任务
-
我有一个枚举： 在枚举成员之间使用方法检查“层次结构”有什么问题吗？我的意思是-当有人将来可能会意外更改顺序时，使用它排除冗长是否有任何缺点。 还是这样做更好：