Я пытался протестировать приложение extjs, и после того, как он успешно установил параметр testAuthenticationToken, он внезапно перестал работать без видимой причины.
Я не мог заставить вышеуказанные ответы работать, поэтому мое решение состояло в том, чтобы пропустить этот кусочек весны в тестовой среде. Я ввел шов вокруг весны так:
public class SpringUserAccessor implements UserAccessor
{
@Override
public User getUser()
{
SecurityContext context = SecurityContextHolder.getContext();
Authentication authentication = context.getAuthentication();
return (User) authentication.getPrincipal();
}
}
Пользователь - здесь пользовательский тип.
Затем я обертываю его в классе, в котором только есть опция для тестового кода для переключения пружины.
public class CurrentUserAccessor
{
private static UserAccessor _accessor;
public CurrentUserAccessor()
{
_accessor = new SpringUserAccessor();
}
public User getUser()
{
return _accessor.getUser();
}
public static void UseTestingAccessor(User user)
{
_accessor = new TestUserAccessor(user);
}
}
Тестовая версия выглядит так:
public class TestUserAccessor implements UserAccessor
{
private static User _user;
public TestUserAccessor(User user)
{
_user = user;
}
@Override
public User getUser()
{
return _user;
}
}
В коде вызова я все еще использую правильного пользователя, загруженного из базы данных:
User user = (User) _userService.loadUserByUsername(username);
CurrentUserAccessor.UseTestingAccessor(user);
Очевидно, что это не подойдет, если вам действительно нужно использовать защиту, но я использую установку без защиты для тестового развертывания. Я думал, что кто-то еще может столкнуться с подобной ситуацией. Это шаблон, который я использовал для макетирования статических зависимостей ранее. Другой альтернативой является то, что вы можете поддерживать статичность класса-оболочки, но я предпочитаю этот, так как зависимости кода более явные, так как вы должны передавать CurrentUserAccessor в классы там, где это требуется.