spring_如何在没有Springockito的情况下模拟Spring bean

spring

我在Spring工作了几年。 但是我总是对XML配置变得多么混乱感到沮丧。 随着各种注释和Java配置可能性的出现，我开始喜欢使用Spring进行编程。 这就是为什么我强烈使用Java配置的原因。 我认为，仅当您需要可视化Spring Integration或Spring Batch流时，XML配置才适用。 希望Spring Tool Suite还将能够可视化这些框架的Java配置。

XML配置的令人讨厌的方面之一是，它通常会导致庞大的XML配置文件。 因此，开发人员经常创建用于集成测试的测试上下文配置。 但是，如果不对生产布线进行测试，那么集成测试的目的是什么？ 这种集成测试几乎没有价值。 因此，我一直试图以可测试的方式设计生产环境。

我除了在创建新项目/模块时要尽可能避免XML配置。 因此，使用Java配置，您可以为每个模块/软件包创建Spring配置，并在主上下文中对其进行扫描(@Configuration也是组件扫描的候选者)。 这样，您可以自然地创建岛屿Spring bean。 这些岛可以很容易地进行隔离测试。

但是我必须承认，并非总是可以按原样测试生产Java配置。 很少需要修改行为或监视某些bean。 有一个名为Springockito的库。 老实说，到目前为止，我还没有使用过它，因为我总是尝试设计Spring配置以避免模拟。 从Springockito的发展速度和未解决问题的数量来看，我有点担心将其引入我的测试套件堆栈中。 实际上，最后一个发行版是在Spring 4发行版之前完成的，带来了诸如“是否可以轻松地将其与Spring 4集成？”之类的问题。 我不知道，因为我没有尝试过。 如果需要在集成测试中模拟Spring bean，我更喜欢纯Spring方法。

Spring提供了@Primary批注，用于指定在注册了两个相同类型的bean时首选哪个bean。 这很方便，因为您可以在集成测试中用伪造的Bean覆盖生产Bean。 让我们探索这种方法以及一些示例上的陷阱。

我选择了这种简单/虚拟的生产代码结构进行演示：

@Repository
public class AddressDao {
	public String readAddress(String userName) {
		return "3 Dark Corner";
	}
}

@Service
public class AddressService {
    private AddressDao addressDao;
    
    @Autowired
    public AddressService(AddressDao addressDao) {
        this.addressDao = addressDao;
    }
    
    public String getAddressForUser(String userName){
        return addressDao.readAddress(userName);
    }
}

@Service
public class UserService {
    private AddressService addressService;

    @Autowired
    public UserService(AddressService addressService) {
        this.addressService = addressService;
    }
    
    public String getUserDetails(String userName){
        String address = addressService.getAddressForUser(userName);
        return String.format("User %s, %s", userName, address);
    }
}

AddressDao单例bean实例注入到AddressService 。 AddressService在UserService也类似使用。

我必须在此阶段警告您。 我的方法对生产代码有些侵入。 为了能够伪造现有的生产Bean，我们必须在集成测试中注册伪造的Bean。 但是这些假bean通常与生产bean在同一包子树中(假设您使用的是标准Maven文件结构：“ src / main / java”和“ src / test / java”)。 因此，当它们在同一包子树中时，将在集成测试期间对其进行扫描。 但是我们不想在所有集成测试中都使用所有bean的假货。 伪造品可能会破坏无关的集成测试。 因此，我们需要一种机制，即如何告诉测试仅使用某些假豆。 这是通过完全从组件扫描中排除假豆来完成的。 集成测试明确定义了正在使用的伪造品(稍后将显示)。 现在让我们看一下从组件扫描中排除假豆的机制。 我们定义了自己的标记注释：

public @interface BeanMock {
}

并在主要的Spring配置中从组件扫描中排除@BeanMock批注。

@Configuration
@ComponentScan(excludeFilters = @Filter(BeanMock.class))
@EnableAutoConfiguration
public class Application {
}

组件扫描的根包是Application类的当前包。 因此，所有上述生产Bean都必须位于同一包装或子包装中。 现在，我们需要为UserService创建集成测试。 让我们窥探地址服务bean。 当然，使用此生产代码进行此类测试没有实际意义，但这仅是示例。 这是我们的间谍豆：

@Configuration
@BeanMock
public class AddressServiceSpy {
	@Bean
	@Primary
	public AddressService registerAddressServiceSpy(AddressService addressService) {
		return spy(addressService);
	}
}

生产AddressService bean是从生产上下文自动连接的，包装到Mockito的间谍中，并注册为AddressService类型的主bean。 @Primary批注确保我们的假bean将用于集成测试而不是生产bean。 @BeanMock批注可确保Application组件扫描无法扫描此bean。 现在让我们看一下集成测试：

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = { Application.class, AddressServiceSpy.class })
public class UserServiceITest {
    @Autowired
    private UserService userService;

    @Autowired
    private AddressService addressService;

    @Test
    public void testGetUserDetails() {
        // GIVEN - spring context defined by Application class

        // WHEN
        String actualUserDetails = userService.getUserDetails("john");

        // THEN
        Assert.assertEquals("User john, 3 Dark Corner", actualUserDetails);
        verify(addressService, times(1)).getAddressForUser("john");
    }
}

@SpringApplicationConfigration批注具有两个参数。 首先( Application.class )声明受测的Spring配置。 第二个参数( AddressServiceSpy.class )指定将用于测试的假bean加载到Spring IoC容器中。 显然，我们可以根据需要使用尽可能多的bean伪造品，但是您不想拥有太多的bean伪造品。 这种方法应该很少使用，如果您经常观察这种模拟，那么您的应用程序或开发团队中的紧密耦合可能会遇到严重的问题。 TDD方法论应该可以帮助您解决此问题。 请记住：“减少嘲笑总是更好！”。 因此，请考虑进行生产设计更改，以减少模拟的使用。 这也适用于单元测试。

在集成测试中，我们可以自动连接此间谍bean并将其用于各种验证。 在这种情况下，我们验证了测试方法userService.getUserDetails addressService.getAddressForUser使用参数“ john”调用了方法addressService.getAddressForUser 。

我再举一个例子。 在这种情况下，我们不会监视生产bean。 我们将模拟它：

@Configuration
@BeanMock
public class AddressDaoMock {
	@Bean
	@Primary
	public AddressDao registerAddressDaoMock() {
		return mock(AddressDao.class);
	}
}

再次，我们重写了生产bean，但是这次我们用Mockito的模拟代替它。 然后，我们可以在集成测试中记录模拟行为：

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = { Application.class, AddressDaoMock.class })
public class AddressServiceITest {
	@Autowired
	private AddressService addressService;

	@Autowired
	private AddressDao addressDao;

	@Test
	public void testGetAddressForUser() {
		// GIVEN
		when(addressDao.readAddress("john")).thenReturn("5 Bright Corner");

		// WHEN
		String actualAddress = addressService.getAddressForUser("john");

		// THEN
		Assert.assertEquals("5 Bright Corner", actualAddress);
	}

	@After
	public void resetMock() {
		reset(addressDao);
	}
}

我们通过@SpringApplicationConfiguration的参数加载@SpringApplicationConfiguration的bean。 在测试方法中，当将“ john”作为参数传递给它时，将存根addressDao.readAddress方法以返回“ 5 Bright Corner”字符串。

但是请记住，记录的行为可以通过Spring上下文进行不同的集成测试。 我们不希望测试相互影响。 因此，您可以通过在测试后重置模拟来避免测试套件中将来出现问题。 这是在方法resetMock完成的。

• 源代码在Github上。

翻译自: https://www.javacodegeeks.com/2014/12/how-to-mock-spring-bean-without-springockito.html

spring