应用程序在分发之前应该经过测试和验证。测试的目的是验证应用程序是否符合功能和非功能要求，并检测应用程序中的错误。
TDD：测试驱动开发
一旦需求和规范得到验证，就可以开始一个称为测试驱动开发的过程。您首先编写测试，然后开发代码。
将根据商定的要求和规范创建测试（测试评审方案）；最初测试会失败，我们将在应用程序中编写代码以确保测试通过。一旦测试通过，我们可以重构应用程序中的代码以改进它并再次启动测试。
此类测试应由分析师设计并由开发人员实施。如果我们注意到某个规范的测试很难开发，我们应该考虑这样一个事实，即该规范可能不正确或至少是不明确的。
多亏了 TDD 技术，我们可以在开发的早期阶段发现任何问题。考虑到解决问题的努力与找到问题所需的时间成正比。
单元和集成测试
单元测试作为类方法验证应用程序的一小部分的功能，并且独立于应用程序的其他单元并隔离。
好的公司，单元测试都是在开发完毕后，自己就进行处理完成了。当然测试人员不是不可以做，主要是侧重点不同。
我们可以将各个单元视为应用程序的各个层。
因此，一个好的单元测试独立于整个应用程序基础设施，如数据库类型和其他层。如果测试方法与其他单元有依赖关系，它们可以被模拟（可能使用像 Mockito 这样的库）。在我们将要做的示例中，我们将测试一个 Service 方法，并且该测试将独立于数据库和 Spring 的上下文（因此该测试适用于任何用于依赖注入的框架）。
集成测试验证应用程序的多个单元的操作。这里使用的框架的上下文也用于测试阶段。
需求示例
根据需求，我们被要求实现 findById 的 REST API 并创建一个 User 模型。要求产品经理提供明确的需求，开发去实现产品提供的需求。
成功返回：
特别是，在 findById 中，客户端必须收到 200 并且在响应正文中收到找到的用户的 JSON。
失败或者不存在返回：
如果没有具有输入 id 的用户，则客户端必须收到带有空正文的 404。
此外，客户端会看到用户的 2 个字段：姓名和地址；名称由姓氏、空格和名字组成。
该项目将具有以下层：
实体将包含具有姓名、姓氏和地址的实体用户
dtos 将包含映射实体 User 的 DTO UserDTO，带有字段名称（“姓氏 + 名字”）和地址
负责将 User 转换为 UserDTO 的转换器，反之亦然
存储库将包含实体用户的 Spring JpaRepository
将包含 UserService 的服务，该服务将从数据库中轻松检索用户并使用转换器将其转换为 DTO
将包含 UserController 的控制器，它负责映射 REST 调用并使用服务的业务逻辑。
第一步：让我们创建实体和 dto
@Entity
public class User implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String name;
private String surname;
private String address;
public User() {}
public User(String name, String surname, String address) {
this.name = name;
this.surname = surname;
this.address = address;
}
//getter, setter, equals and hashcode
}
@Entity
public class UserDTO {
//surname + name
private String name;
private String address;
public UserDTO() {}
public UserDTO(String name, String address) {
this.name = name;
this.address = address;
}
//getter, setter, equals and hashcode
}
第二步：让我们创建转换器
@Component
public class UserConverter {
public UserDTO userToUserDTO(User user) {
return new UserDTO(user.getSurname() + " " + user.getName(), user.getAddress());
}
public User userDTOToUser(UserDTO userDTO) {
String[] surnameAndName = userDTO.getName().split(" ");
return new User(surnameAndName[1], surnameAndName[0], userDTO.getAddress());
}
}
第三步：让我们为 User 实体创建一个存储库
public interface UserRepository extends JpaRepository
}
第四步：让我们用 findById 方法创建服务
@Service
public class UserServiceImpl implements UserService {
private static final Logger LOGGER = LoggerFactory.getLogger(UserServiceImpl.class);
private UserRepository userRepository;
private UserConverter userConverter;
public UserServiceImpl(UserRepository userRepository, UserConverter userConverter) {
this.userRepository = userRepository;
this.userConverter = userConverter;
}
@Override
public UserDTO findById(Long id) {
return null;
}
}
正如我们所见，该方法目前返回 null。我们将在运行测试后实现该功能。
第五步：我们创建测试类来测试服务的findById方法
当输入中提供有效值时，甚至当提供无效值时，良好的测试应该验证方法的行为。
该服务依赖于存储库和转换器。我们对存储库的实现不感兴趣，因此模拟它是一个好主意。对于转换器，我们可以考虑做同样的事情，但由于它是一个非常琐碎的类，我们可以考虑在测试中使用真正的类，但不带出Spring的上下文。
建立一个测试类
@ExtendWith(MockitoExtension.class)
public class UserServiceTest {
@Mock
private UserRepository userRepository;
@Spy
private UserConverter userConverter;
private UserService userService;
@BeforeEach
public void init() {
userService = new UserServiceImpl(userRepository, userConverter);
}
@Test
public void findByIdSuccess() {
User user = new User("Vincenzo", "Racca", "via Roma");
user.setId(1L);
when(userRepository.findById(anyLong())).thenReturn(Optional.of(user));
UserDTO userDTO = userService.findById(1L);
verify(userRepository, times(1)).findById(anyLong());
assertNotNull(userDTO);
String[] surnameAndName = userDTO.getName().split( " ");
assertEquals(2, surnameAndName.length);
assertEquals(user.getSurname(), surnameAndName[0]);
assertEquals(user.getName(), surnameAndName[1]);
assertEquals(user.getAddress(), userDTO.getAddress());
}
}
我们来分析一下代码：
@ExtendWith(MockitoExtension.class) 允许我们使用 Mockito 库的 mockato 上下文。 @ExtendWith 也对应于 JUnit 4 的 @RunWith。
我们使用 @Mock 注释存储库，因为我们希望 Mockito 创建接口的 mockata 实现。
我们使用@Spy 对转换器进行注释，以向 Mockito 表明我们想要使用真正的类。
我们使用 @BeforeEach 注释每次运行测试方法时初始化 userService 的 init 方法。由于我们使用了构造函数依赖注入而不是字段注入，我们只需要在构造函数中传入 mockato 存储库即可创建服务。 @BeforeEach 对应于 JUnit 4 的 @Before 注解。
当然这里也可用junit5或者是testng
我们来分析一下测试：
我们期望对于任何输入 id，存储库将返回一个名为 Vincenzo、姓氏 Racca 和通过 Roma 的地址的用户。为此，我们将 Mockito 的静态方法与 anyLong（指示任何 id）一起使用，然后使用 thenReturn 指示我们期望从该方法中获得的返回值。当我们调用该服务时，我们期望返回一个名为 Racca Vincenzo 和地址 via Roma.\ 的 UserDTO。通过验证，我们验证服务调用存储库的 findById 1 次。然后遵循各种琐碎的断言。
我们执行测试：它在调用 verify 时已经失败，因为服务方法从未调用存储库；
第六步：让我们修复方法
public class UserNotFoundException extends RuntimeException {
public UserNotFoundException(Long id) {
super("User with id " + id + " not found!");
}
}
@Test
public void findByIdUnSuccess() {
when(userRepository.findById(anyLong())).thenReturn(Optional.empty());
UserNotFoundException exp = assertThrows(UserNotFoundException.class, () -> userService.findById(1L));
assertEquals("User with id 1 not found!", exp.getMessage());
}
我们非常简单地告诉 Mockito，对于任何 id，存储库都不会找到任何用户。使用 assertThrows 我们返回我们期望由服务启动的异常，然后我们在异常消息上写一个断言。这种测试在 JUnit 5 中是可能的。实际上，在 JUnit 4 中，我们可以验证该方法是否启动了异常，但是一旦启动了错误，您就无法继续进行断言。
显然测试失败，所以让我们修复方法。
现在测试通过了，我们可以评估以改进代码而不会忘记重新测试该方法。
第七步：重构方法
@Override
public UserDTO findById(Long id) {
User user = userRepository.findById(id).orElseThrow(() -> {
UserNotFoundException exp = new UserNotFoundException(id);
LOGGER.error("Exception is UserServiceImpl.findById", exp);
return exp;
});
return userConverter.userToUserDTO(user);
}
结论
我们通过使用 JUnit 5 开发单元测试并在 Mockito 的帮助下模拟测试不感兴趣的单元，简要了解了测试驱动开发的工作原理。在下一篇文章中，我们将通过创建控制器来继续开发需求，我们将使用 Spring Boot、JUnit 5 和 H2 作为内存数据库编写集成测试。