请问如何为具有不同实现的接口编写junit 5测试?
例如,我有一个接口Solution
,具有诸如SolutionI
,SolutionII
之类的不同实现,我可以只编写一个测试类来对两者进行测试吗?
有一个post显示了一个示例,但是如果需要调用多个测试方法,则必须为每个测试方法传递参数。
请问是否有优雅方式,如Junit4中使用的方式
在Junit4中,我有一个非常优雅的代码示例,如下所示
@RunWith(Parameterized.class)
public class SolutionTest {
private Solution solution;
public SolutionTest(Solution solution) {
this.solution = solution;
}
@Parameterized.Parameters
public static Collection<Object[]> getParameters() {
return Arrays.asList(new Object[][]{
{new SolutionI()},
{new SolutionII()}
});
}
// normal test methods
@Test
public void testMethod1() {
}
}
Junit 5声称ExtendWith()
类似,我尝试了以下代码
@ExtendWith(SolutionTest.SolutionProvider.class)
public class SolutionTest {
private Solution solution;
public SolutionTest(Solution solution) {
System.out.println("Call constructor");
this.solution = solution;
}
@Test
public void testOnlineCase1() {
assertEquals(19, solution.testMethod(10));
}
@Test
public void testOnlineCase2() {
assertEquals(118, solution.testMethod(100));
}
static class SolutionProvider implements ParameterResolver {
private final Solution[] solutions = {
new SolutionI(),
new SolutionII()
};
private static int i = 0;
@Override
public boolean supportsParameter(ParameterContext parameterContext, ExtensionContext extensionContext) throws ParameterResolutionException {
return parameterContext.getParameter().getType() == Solution.class;
}
@Override
public Object resolveParameter(ParameterContext parameterContext, ExtensionContext extensionContext) throws ParameterResolutionException {
System.out.println(i);
return solutions[i++];
}
}
}
不幸的是,testMethod1
使用的是SolutionI
,而testMethod2
使用的是SolutionII
,这很有意义,我不知道这是否对您有所启发。 / p>
非常感谢您的帮助
答案 0 :(得分:1)
例如,我有一个界面解决方案, 解决方案I,解决方案II之类的实现我只能编写一个测试 上课同时测试两者?
简短的答案是您不应这样做。最佳实践是,对于UT,每个实现都将拥有自己的测试类,这样,如果一个实现发生更改,则只会影响相关的测试。 请在下面找到一些其他想法:
如果您有同一个接口的两个实现,我想 逻辑是不同的,否则为什么要麻烦两个实现 首先?因此,您应该有两组测试;
如果两个实现之间有相同的逻辑,则应将其放在一个抽象类中,该类将由您的实现扩展。
ParameterizedTest不应被滥用以偏离最佳模式;
根据您的用例,为避免测试代码的重复,在JUnit5中,您确实可以按照文档中extensions的说明使用here。
答案 1 :(得分:1)
Jupiter完全根据您的目的提供Test interfaces-测试界面合同。
例如,让我们有一个用于字符串诊断协定的接口以及该协定之后的两个实现,但是利用了不同的实现思路:
public interface StringDiagnose {
/**
* Contract: a string is blank iff it consists of whitespace chars only
* */
boolean isTheStringBlank(String string);
}
public class DefaultDiagnose implements StringDiagnose {
@Override
public boolean isTheStringBlank(String string) {
return string.trim().length() == 0;
}
}
public class StreamBasedDiagnose implements StringDiagnose {
@Override
public boolean isTheStringBlank(String string) {
return string.chars().allMatch(Character::isWhitespace);
}
}
根据推荐的方法,您将创建 test接口,以验证default
方法中的诊断 contract ,并将与实现相关的部分暴露给钩子: / p>
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertTrue;
import static org.junit.jupiter.api.Assertions.assertFalse;
public interface StringDiagnoseTest<T extends StringDiagnose> {
T createDiagnose();
@Test
default void blankCheckFollowsContract(){
assertTrue(createDiagnose().isTheStringBlank("\t\n "));
assertFalse(createDiagnose().isTheStringBlank("\t\n ! \r\n"));
}
}
,然后针对每个特定的解决方案实现此 test接口:
class DefaultDiagnoseTest implements StringDiagnoseTest<DefaultDiagnose> {
@Override
public DefaultDiagnose createDiagnose() {
return new DefaultDiagnose();
}
}
class StreamBasedDiagnoseTest implements StringDiagnoseTest<StreamBasedDiagnose> {
@Override
public StreamBasedDiagnose createDiagnose() {
return new StreamBasedDiagnose();
}
}
使用更多的钩子和非default
接口方法来测试同名解决方案的各个方面(例如性能),并在接口实现中定义新的测试,以实现完全不同的实现特性。
答案 2 :(得分:1)
抱歉暂时没有回复这个帖子。与 lotor 的回答相比,我发现了我目前正在采用的其他一些方法:
@ParameterizedTest
@MethodSource("solutionStream")
void testCase(Solution solution) {
// add your test
}
static Stream<Solution> solutionStream() {
return Stream.of(
new SolutionI(),
new SolutionII()
);
}
构造函数需要参数(非类型安全)
@ParameterizedTest
@MethodSource("solutionStream")
void testOnlineCase(Class<Solution> solutionClass) throws NoSuchMethodException, IllegalAccessException,
InvocationTargetException, InstantiationException {
Solution solution = solutionClass.getConstructor(Integer.TYPE).newInstance(2);
}
static Stream<Class> solutionStream() {
return Stream.of(
SolutionI.class
);
}