我正在尝试使用junit5和pitest。 我的测试代码如下:
// [...]
InputStream istream = this.getClass().getResourceAsStream("/" + file.getName());
if (istream == null) // 1. negated condition -> suvived
{
istream = Files.newInputStream(this.files.get(varname).toPath(), StandardOpenOption.READ);
}
try (BufferedReader reader = new BufferedReader(new InputStreamReader(istream, StandardCharsets.UTF_8))) // 2. removed call to java/io/BufferedReader::close → SURVIVED // 3. removed call to java/lang/Throwable::addSuppressed → SURVIVED
{
// [...]
} // 4. removed call to java/io/BufferedReader::close → SURVIVED
在这小段代码中,我留下了4个想杀死的幸存突变。可以通过添加/更改测试或重构代码来终止。
我的问题是,第一个突变是同等的突变-如果我不知道如何将其重构。 try-resource-statement隐含了其他三个突变。
所以我的问题是如何重构这4个突变?因为我确信它们不能被其他/更改的测试杀死。
答案 0 :(得分:1)
只有在if语句的两边函数的可观察行为相同时,第一个变量才等效。
对于这种情况,'file'和'this.files.get(varname)'将需要始终解析为相同的输入流。
如果它们可以解析为不同的输入流,则可以构建测试以杀死突变体。
如果他们总是会解决同一件事,那么为什么需要第一个分支?除非存在某些无法测试的问题(例如性能),否则不需要第一个分支,并且始终可以从“ this.files.get(varname).toPath()”解析流。
其他突变体有些棘手。
它们等同于处理不可单元测试的问题(资源管理)。更重要的是,它们是“垃圾”,因为它们是编译器构造,不会直接映射回代码。
Pitest试图过滤掉像这样的垃圾变量,但是过滤并不完善,因为它们在字节码中没有明确地标识为编译器构造。
如果我将您的代码段粘贴到文件中并进行编辑以进行编译,则1.4.8版本会正确过滤掉所有这些变体。如果您可以粘贴一个完整的可重现该问题的可编译类,那么我可以看到是否可以对过滤进行调整以在上下文中拾取这些突变体。