我已经为学习进行了简单的申请，我想编写一些单元/插入测试。我阅读了一些有关可以模拟创建新数据库进行测试的数据库的信息。我将复制其中写的代码。我希望有人能向我解释如何模拟数据库。
public class UserServiceImpl implements UserService {
@Autowired
private UserOptionsDao uod;
@Override
public User getUser(int id) throws Exception {
if (id < 1) {
throw new InvalidParameterException();
}
return uod.getUser(id);
}
@Override
public User changeUserEmail(int id, String email) {
if (id < 1) {
throw new InvalidParameterException();
}
String[] emailParts = email.split("@");
if (emailParts[0].length() < 5) {
throw new InvalidParameterException();
} else if (!emailParts[1].equals("email.com")) {
throw new InvalidParameterException();
}
return uod.changeUserEmail(id, email);
}
以上是我要使用模拟数据库测试的部分代码。
最佳答案
通常，您有三个选择：
按照@Betlista的建议模拟UserOptionsDao返回的数据，从而创建一个“伪” DAO对象。
在测试开始时，使用诸如HSQLDB之类的内存数据库来创建包含模拟数据的数据库，或者
使用Docker容器之类的东西启动一个MySQL或类似的实例，并用数据填充它，因此您可以根据需要重新启动它。
这些解决方案都不是完美的。
使用＃1，您的测试将跳过对数据库进行身份验证和查找数据的中间步骤。这就使您的代码的一部分未经测试，正如他们所说，“魔鬼在细节中”。人们在尝试部署DAO时，经常会遇到这样的问题。
使用＃2，您可以连接到实际的数据库，但是必须确保在生产代码中使用的是完全相同类型的数据库或兼容的数据库。这也使调试变得很痛苦，因为如果出现问题，您必须暂停测试以查看数据库的内容。
使用＃3，您可以避免＃1和＃2的所有问题，但随后必须连接所有Docker组件。 （我是doing this right now，我也遇到了问题）。但是，优点是，像＃2一样，您可以一次设置所有测试数据，并确保所选的生产数据库与单元测试完全相同。
在您的情况下，我将选择＃2，因为该应用程序仅用于学习目的。是的，我知道这是一个冗长的答案，但是随着经验的积累，您可能会想知道如何“扩大规模”。