我正在尝试为接口 Foo 编写参数化测试，该接口声明一个方法 getFooEventInt(int, int)。我编写了一个适用于 Foo 的单个实例（FooImpl 对象）的参数化测试。
public class FooTest {
@ParameterizedTest
@MethodSource("getFooEvenIntProvider")
public void getFooEvenIntTest(int seed, int expectedResult) {
Foo foo = new FooImpl();
Assertions.assertEquals(expectedResult, foo.getFooEvenInt(seed));
}
private static Stream getFooEvenIntProvider() {
return Stream.of(
Arguments.of(-2, 0),
Arguments.of(-1, 0),
Arguments.of( 0, 2),
Arguments.of( 1, 2),
);
}
}
但是，我希望能够针对提供的 Foo 实现实例列表调用 getFooEvenIntTest(int, int) ，然后每次迭代都使用提供的种子/预期结果值列表。
我意识到我可以这样做...
public class FooTest {
@ParameterizedTest
@MethodSource("getFooProvider")
public void getFooImplEvenIntTest(Foo foo) {
int[] expectedResult = { 0, 0, 2, 2 };
int[] seed = { …我曾考虑将其命名为“Java 异常的海森堡不确定性推论”，但这 (a) 太笨拙，(b) 不够描述。
BLUF：我试图在针对 Spring Boot 应用程序的 JUnit 5 测试中捕获当元组被持久化到违反约束的数据库表（标记为“唯一”的列中的重复值）时引发的异常。我可以在 try-catch 块中捕获异常，但不能使用 JUnit 的“assertThrows()”。
细化
为了便于复制，我将代码范围缩小到只有实体和存储库，以及两个测试（一个有效，另一个是这篇文章的原因）。同样为了便于复制，我使用 H2 作为数据库。
我读到有潜在的事务范围问题，这可能导致约束生成的异常不会在调用方法的范围内抛出。我在语句“foos.aave(foo);”周围用一个简单的try-catch块确认了这一点。在 shouldThrowExceptionOnSave() 中（没有“tem.flush()”语句）。
我决定使用 TestEntityManager.flush() 来强制事务提交/结束，并且能够在 try-catch 块中成功捕获异常。但是，它不是预期的 DataIntegrityViolationException，而是 PersistenceException。
我尝试使用类似的机制（即，使用 TestEntityManager.flush() 来强制 assertThrows() 语句中的问题。但是，“不高兴”。
当我尝试“assertThrows(PersistenceException.class,...”) 时，该方法以 DataIntegrityViolationException 终止。
当我尝试“assertThrows(DataIntegrityViolationException.class,...”时，我实际上收到了一条 JUnit 错误消息，表明预期的 DataIntegrityViolationException 与实际异常不匹配。即...javax.persistence.PersistenceException！
任何帮助/见解将不胜感激。
添加注意： shouldThrowExceptionOnSave() 中的 try-catch 块只是为了查看捕获到什么异常。
实体类
package com.test.foo;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Id;
@Entity
public class Foo {
@Id
@Column(name = "id",
nullable = false,
unique = true)
private String id;
@Column(name = "name", …不确定这是否会被视为“合法问题”或“纯粹基于意见”，但是在 Spring Boot 应用程序中直接测试存储库是否有“最佳实践”？或者，任何集成测试都应该只针对关联的服务吗？
这个问题的原因很简单：在大多数情况下，Spring Boot 应用程序中的存储库不包含项目生成的代码。最好的情况是，它包含 Spring 为其生成实现的项目定义的方法签名（假设命名约定正确）。
谢谢...