我目前正在使用Java 17、Dropwizard和JUnit 5进行一个Java项目，我专注于改进我的单元测试和采用测试驱动开发(TDD)实践.我的应用程序通过DAO接口与数据库交互，我正在探索测试这些交互的最佳方法，特别是对于执行诸如将数据插入数据库但不返回值的操作的方法.
考虑到这些方法的性质，我考虑了两种主要的测试方法:
我知道假实现通过避免设置真实数据库连接的开销来提供速度和简单性，使它们非常适合单元测试.另一方面，内存数据库提供了一个更真实的测试环境，这似乎有利于集成测试，以确保我的SQL查询和事务按预期的方式运行.
我的问题:
我的目标是一种测试策略，它不仅确保可靠性和可维护性，而且与TDD的最佳实践相一致.您可以分享的任何见解、经验或建议都将不胜感激.
谢谢你！
在TDD环境中，考虑到测试中速度和真实性之间的平衡，对于不返回值的测试方法，您会推荐哪种方法？
测试行为，而不是方法.正如你提到的，你想要的行为是你可以成功地编写一个项目，而你测试这种行为的方式是你try 并阅读项目.这可能看起来像
@Test
public void it_can_save_an_item() {
MyDao dao = new MyDao();
Item item = new Item("foo", "bar");
dao.save(item);
List<Item> savedItems = dao.findAll();
assertEquals(item, savedItems.get(0));
}
就我个人而言，我不使用内存数据库，原因与其他人在上面提到的相同.
我倾向于采用的方法是使用一个假的，并集成测试真正的实现，使用契约来确保两个抽象版本的行为是相同的.例如，参见https://quii.gitbook.io/learn-go-with-tests/testing-fundamentals/working-without-mocks个关于假货和合约的例子(Go语言中有例子，但建议实际上与语言无关).
这里我的观点来自于从外到内(或"伦敦风格")TDD，在这种情况下，系统的设计从验收测试中脱颖而出.也就是说，您正在弄清楚您需要什么抽象，以及它们应该如何看起来，而伪造是一种相当轻量级的方式来帮助您(但还有其他原因—参见上面的链接).
我想，如果您正在做更多的由内而外("芝加哥风格")，并且正在对需要DAO的组件进行单元测试，您仍然希望获得同样的信心——您可以使用一个运行得像真实的DAO版本来测试您的组件.