如何通过 EvoSuite 生成失败的测试用例？

Question

我在学习使用 Evosuite 的时候，写了一些错误的方法。例如其中一个类的方法A直接调用 interface 的抽象方法B，EvoSuite 生成了一个mock forB来避免案例失败：import org.junit.Test;import static org.junit.Assert.*;import static org.evosuite.shaded.org.mockito.Mockito.*;import MockTest.A;import MockTest.B;import org.evosuite.runtime.EvoRunner;import org.evosuite.runtime.EvoRunnerParameters;import org.evosuite.runtime.ViolatedAssumptionAnswer;import org.junit.runner.RunWith;@RunWith(EvoRunner.class) @EvoRunnerParameters(useVNET = true, separateClassLoader = true, useJEE = true) public class A_ESTest extends A_ESTest_scaffolding {  @Test(timeout = 4000)  public void test0()  throws Throwable  {      A a0 = new A();      B b0 = mock(B.class, new ViolatedAssumptionAnswer());      doReturn((String) null).when(b0).get(anyInt());      String string0 = a0.test(b0);      assertNull(string0);  }}对于可能发生被零除的方法，EvoSuite 生成的测试用例甚至会捕获异常以确保测试用例通过：import org.junit.Test;import static org.junit.Assert.*;import static org.evosuite.runtime.EvoAssertions.*;import org.evosuite.runtime.EvoRunner;import org.evosuite.runtime.EvoRunnerParameters;import org.junit.runner.RunWith;import test.Case2;@RunWith(EvoRunner.class) @EvoRunnerParameters(useVNET = true, separateClassLoader = true, useJEE = true) public class Case2_ESTest extends Case2_ESTest_scaffolding {  @Test(timeout = 4000)  public void test8()  throws Throwable  {      Case2 case2_0 = new Case2();      // Undeclared exception!      try {         case2_0.add(6, 0);        fail("Expecting exception: ArithmeticException");      } catch(ArithmeticException e) {         //         // / by zero         //         verifyException("test.Case2", e);      }  }}EvoSuite 自动生成的测试用例是否总是通过，如这些示例中所示？如何让 EvoSuite 生成可能失败的测试用例，从而可以直接供开发人员使用？

Answer 1

EvoSuite 自动生成的测试用例是否总是通过，如这些示例中所示？

EvoSuite 站点提供了大量出版物列表，描述了该软件的理论和操作。然而，将其归结为最简单的术语，该软件会生成测试用例，以检测被测软件中的突变，这些突变会改变其行为并且不会被现有测试捕获。因此，被测软件的实际行为是基线，因此在未修改的软件上生成的任何测试都不应该失败。

如何让 EvoSuite 生成可能失败的测试用例，从而可以直接供开发人员使用？

我看不出任何软件都可以做到这一点。EvoSuite 如何将软件的任何特定行为识别为不正确，从而生成失败案例？考虑您的除以零示例。当被测方法ArithmeticException的第二个参数为 0 时，它显然抛出an。EvoSuite 怎么知道这不是方法应该做的？

如果软件可以先验地辨别出被测代码应该做什么，那么对这一非凡壮举的更好应用就是让它（重新）编写实际代码。

但这并不意味着开发人员不能使用 EvoSuite 测试。开发人员至少可以通过以下方式使用它们：

1. 开发人员可以分析生成的测试以检测被测软件表现出的意外行为。这是一件非常酷且有价值的事情，但也许它不适合您“直接”使用测试。

2. 许多测试将正确断言预期行为，并且可以在软件的测试套件中按原样使用。生成的整体套件将提供比许多软件更好的回归保护。

3. 即使断言不正确行为的测试也可能有用，不是为了提前检测缺陷，而是在通过其他方式检测到缺陷后对其进行表征。例如，假设您从该领域得到一个报告，该方法widget.frob()抛出了一个意外的UpYoursException，但导致它的情况不清楚。很有可能您的 EvoSuite 测试已经显示了至少一种从受影响的方法中引发此异常的方法。这可能不符合“直接”使用测试的条件，但这是不尝试提前清除不正确的自动测试用例（同时不修复被测代码）的理由。

底线：EvoSuite 是对手写测试用例的补充，而不是替代它们。