Spring Boot 2.1 - @WebMvcTest without Spring Security Auto-Configuration
Before migrating to Spring Boot 2.1, we had a couple of controller tests in our services utilizing @WebMvcTest in combination with @AutoConfigureMockMvc:
@WebMvcTest(SomeController.class)
@AutoConfigureMockMvc(secure = false)
public class SomeControllerTests { ... }
This had the effect that the Spring Security configuration was disabled and you could run MVC tests without mocking OAuth/JWT.
In Spring Boot 2.1, the secured attribute is deprecated and the release notes mention that
[...] @WebMvcTest looks for a WebSecurityConfigurer bean [...].
In order to avoid the deprecated secured attribute and loading of our WebSecurityConfigurer we rewrote our tests to:
@WebMvcTest(
value = SomeController.class,
excludeFilters = @ComponentScan.Filter(type = FilterType.ASSIGNABLE_TYPE, classes = WebSecurityConfigurer.class),
excludeAutoConfiguration = MockMvcSecurityAutoConfiguration.class)
public class SomeControllerTests { ... }
The question is: is there a more compact way in Spring Boot 2.1 to define such tests?
spring-boot
add a comment |
Before migrating to Spring Boot 2.1, we had a couple of controller tests in our services utilizing @WebMvcTest in combination with @AutoConfigureMockMvc:
@WebMvcTest(SomeController.class)
@AutoConfigureMockMvc(secure = false)
public class SomeControllerTests { ... }
This had the effect that the Spring Security configuration was disabled and you could run MVC tests without mocking OAuth/JWT.
In Spring Boot 2.1, the secured attribute is deprecated and the release notes mention that
[...] @WebMvcTest looks for a WebSecurityConfigurer bean [...].
In order to avoid the deprecated secured attribute and loading of our WebSecurityConfigurer we rewrote our tests to:
@WebMvcTest(
value = SomeController.class,
excludeFilters = @ComponentScan.Filter(type = FilterType.ASSIGNABLE_TYPE, classes = WebSecurityConfigurer.class),
excludeAutoConfiguration = MockMvcSecurityAutoConfiguration.class)
public class SomeControllerTests { ... }
The question is: is there a more compact way in Spring Boot 2.1 to define such tests?
spring-boot
add a comment |
Before migrating to Spring Boot 2.1, we had a couple of controller tests in our services utilizing @WebMvcTest in combination with @AutoConfigureMockMvc:
@WebMvcTest(SomeController.class)
@AutoConfigureMockMvc(secure = false)
public class SomeControllerTests { ... }
This had the effect that the Spring Security configuration was disabled and you could run MVC tests without mocking OAuth/JWT.
In Spring Boot 2.1, the secured attribute is deprecated and the release notes mention that
[...] @WebMvcTest looks for a WebSecurityConfigurer bean [...].
In order to avoid the deprecated secured attribute and loading of our WebSecurityConfigurer we rewrote our tests to:
@WebMvcTest(
value = SomeController.class,
excludeFilters = @ComponentScan.Filter(type = FilterType.ASSIGNABLE_TYPE, classes = WebSecurityConfigurer.class),
excludeAutoConfiguration = MockMvcSecurityAutoConfiguration.class)
public class SomeControllerTests { ... }
The question is: is there a more compact way in Spring Boot 2.1 to define such tests?
spring-boot
Before migrating to Spring Boot 2.1, we had a couple of controller tests in our services utilizing @WebMvcTest in combination with @AutoConfigureMockMvc:
@WebMvcTest(SomeController.class)
@AutoConfigureMockMvc(secure = false)
public class SomeControllerTests { ... }
This had the effect that the Spring Security configuration was disabled and you could run MVC tests without mocking OAuth/JWT.
In Spring Boot 2.1, the secured attribute is deprecated and the release notes mention that
[...] @WebMvcTest looks for a WebSecurityConfigurer bean [...].
In order to avoid the deprecated secured attribute and loading of our WebSecurityConfigurer we rewrote our tests to:
@WebMvcTest(
value = SomeController.class,
excludeFilters = @ComponentScan.Filter(type = FilterType.ASSIGNABLE_TYPE, classes = WebSecurityConfigurer.class),
excludeAutoConfiguration = MockMvcSecurityAutoConfiguration.class)
public class SomeControllerTests { ... }
The question is: is there a more compact way in Spring Boot 2.1 to define such tests?
spring-boot
spring-boot
asked Nov 20 '18 at 9:20
Andre SteingressAndre Steingress
3,3872022
3,3872022
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Yes, rather than working around the fact the flag is deprecated, you should embrace the fact that this is going in that direction going forward.
As of Spring Boot 2.1, if you have Spring Security, your tests will be secured using your custom configuration. What is the actual problem with that?
If you don't want to authenticate for certain tests, just use Spring Security's test infrastructure and add @WithMockUser.
Our services run with Spring Security OAuth2. I didn't have a detailed look but I think in that scenario@WithMockUserwon't help much. But thanks anyway, I wasn't sure we were on the right track.
– Andre Steingress
Nov 20 '18 at 9:52
The idea of slicing is to enable only what is necessary. So I do not want to embrace activating much more code than I need.
– Max
Nov 26 '18 at 17:20
The idea of slicing is to enable what makes sense for a particular layer of your application. If you disagree with security being enabled for web tests, you can always create your own slice.
– Stephane Nicoll
Nov 27 '18 at 17:04
How can I fallback to the previous behavior? I don't want to use the deprecated flag and even if I do controllers that need to inject the principal will require some security configuration, and in order to provide that I'll need to set up my database infrastructure so all the beans can be wired properly.
– Jayr Motta
Feb 4 at 7:24
The flag has been deprecated because that behaviour is going away. The last part of my answer mentions how to enable a security context in test.
– Stephane Nicoll
Feb 4 at 9:10
|
show 2 more comments
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53389774%2fspring-boot-2-1-webmvctest-without-spring-security-auto-configuration%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Yes, rather than working around the fact the flag is deprecated, you should embrace the fact that this is going in that direction going forward.
As of Spring Boot 2.1, if you have Spring Security, your tests will be secured using your custom configuration. What is the actual problem with that?
If you don't want to authenticate for certain tests, just use Spring Security's test infrastructure and add @WithMockUser.
Our services run with Spring Security OAuth2. I didn't have a detailed look but I think in that scenario@WithMockUserwon't help much. But thanks anyway, I wasn't sure we were on the right track.
– Andre Steingress
Nov 20 '18 at 9:52
The idea of slicing is to enable only what is necessary. So I do not want to embrace activating much more code than I need.
– Max
Nov 26 '18 at 17:20
The idea of slicing is to enable what makes sense for a particular layer of your application. If you disagree with security being enabled for web tests, you can always create your own slice.
– Stephane Nicoll
Nov 27 '18 at 17:04
How can I fallback to the previous behavior? I don't want to use the deprecated flag and even if I do controllers that need to inject the principal will require some security configuration, and in order to provide that I'll need to set up my database infrastructure so all the beans can be wired properly.
– Jayr Motta
Feb 4 at 7:24
The flag has been deprecated because that behaviour is going away. The last part of my answer mentions how to enable a security context in test.
– Stephane Nicoll
Feb 4 at 9:10
|
show 2 more comments
Yes, rather than working around the fact the flag is deprecated, you should embrace the fact that this is going in that direction going forward.
As of Spring Boot 2.1, if you have Spring Security, your tests will be secured using your custom configuration. What is the actual problem with that?
If you don't want to authenticate for certain tests, just use Spring Security's test infrastructure and add @WithMockUser.
Our services run with Spring Security OAuth2. I didn't have a detailed look but I think in that scenario@WithMockUserwon't help much. But thanks anyway, I wasn't sure we were on the right track.
– Andre Steingress
Nov 20 '18 at 9:52
The idea of slicing is to enable only what is necessary. So I do not want to embrace activating much more code than I need.
– Max
Nov 26 '18 at 17:20
The idea of slicing is to enable what makes sense for a particular layer of your application. If you disagree with security being enabled for web tests, you can always create your own slice.
– Stephane Nicoll
Nov 27 '18 at 17:04
How can I fallback to the previous behavior? I don't want to use the deprecated flag and even if I do controllers that need to inject the principal will require some security configuration, and in order to provide that I'll need to set up my database infrastructure so all the beans can be wired properly.
– Jayr Motta
Feb 4 at 7:24
The flag has been deprecated because that behaviour is going away. The last part of my answer mentions how to enable a security context in test.
– Stephane Nicoll
Feb 4 at 9:10
|
show 2 more comments
Yes, rather than working around the fact the flag is deprecated, you should embrace the fact that this is going in that direction going forward.
As of Spring Boot 2.1, if you have Spring Security, your tests will be secured using your custom configuration. What is the actual problem with that?
If you don't want to authenticate for certain tests, just use Spring Security's test infrastructure and add @WithMockUser.
Yes, rather than working around the fact the flag is deprecated, you should embrace the fact that this is going in that direction going forward.
As of Spring Boot 2.1, if you have Spring Security, your tests will be secured using your custom configuration. What is the actual problem with that?
If you don't want to authenticate for certain tests, just use Spring Security's test infrastructure and add @WithMockUser.
answered Nov 20 '18 at 9:41
Stephane NicollStephane Nicoll
20.3k45458
20.3k45458
Our services run with Spring Security OAuth2. I didn't have a detailed look but I think in that scenario@WithMockUserwon't help much. But thanks anyway, I wasn't sure we were on the right track.
– Andre Steingress
Nov 20 '18 at 9:52
The idea of slicing is to enable only what is necessary. So I do not want to embrace activating much more code than I need.
– Max
Nov 26 '18 at 17:20
The idea of slicing is to enable what makes sense for a particular layer of your application. If you disagree with security being enabled for web tests, you can always create your own slice.
– Stephane Nicoll
Nov 27 '18 at 17:04
How can I fallback to the previous behavior? I don't want to use the deprecated flag and even if I do controllers that need to inject the principal will require some security configuration, and in order to provide that I'll need to set up my database infrastructure so all the beans can be wired properly.
– Jayr Motta
Feb 4 at 7:24
The flag has been deprecated because that behaviour is going away. The last part of my answer mentions how to enable a security context in test.
– Stephane Nicoll
Feb 4 at 9:10
|
show 2 more comments
Our services run with Spring Security OAuth2. I didn't have a detailed look but I think in that scenario@WithMockUserwon't help much. But thanks anyway, I wasn't sure we were on the right track.
– Andre Steingress
Nov 20 '18 at 9:52
The idea of slicing is to enable only what is necessary. So I do not want to embrace activating much more code than I need.
– Max
Nov 26 '18 at 17:20
The idea of slicing is to enable what makes sense for a particular layer of your application. If you disagree with security being enabled for web tests, you can always create your own slice.
– Stephane Nicoll
Nov 27 '18 at 17:04
How can I fallback to the previous behavior? I don't want to use the deprecated flag and even if I do controllers that need to inject the principal will require some security configuration, and in order to provide that I'll need to set up my database infrastructure so all the beans can be wired properly.
– Jayr Motta
Feb 4 at 7:24
The flag has been deprecated because that behaviour is going away. The last part of my answer mentions how to enable a security context in test.
– Stephane Nicoll
Feb 4 at 9:10
Our services run with Spring Security OAuth2. I didn't have a detailed look but I think in that scenario
@WithMockUser won't help much. But thanks anyway, I wasn't sure we were on the right track.– Andre Steingress
Nov 20 '18 at 9:52
Our services run with Spring Security OAuth2. I didn't have a detailed look but I think in that scenario
@WithMockUser won't help much. But thanks anyway, I wasn't sure we were on the right track.– Andre Steingress
Nov 20 '18 at 9:52
The idea of slicing is to enable only what is necessary. So I do not want to embrace activating much more code than I need.
– Max
Nov 26 '18 at 17:20
The idea of slicing is to enable only what is necessary. So I do not want to embrace activating much more code than I need.
– Max
Nov 26 '18 at 17:20
The idea of slicing is to enable what makes sense for a particular layer of your application. If you disagree with security being enabled for web tests, you can always create your own slice.
– Stephane Nicoll
Nov 27 '18 at 17:04
The idea of slicing is to enable what makes sense for a particular layer of your application. If you disagree with security being enabled for web tests, you can always create your own slice.
– Stephane Nicoll
Nov 27 '18 at 17:04
How can I fallback to the previous behavior? I don't want to use the deprecated flag and even if I do controllers that need to inject the principal will require some security configuration, and in order to provide that I'll need to set up my database infrastructure so all the beans can be wired properly.
– Jayr Motta
Feb 4 at 7:24
How can I fallback to the previous behavior? I don't want to use the deprecated flag and even if I do controllers that need to inject the principal will require some security configuration, and in order to provide that I'll need to set up my database infrastructure so all the beans can be wired properly.
– Jayr Motta
Feb 4 at 7:24
The flag has been deprecated because that behaviour is going away. The last part of my answer mentions how to enable a security context in test.
– Stephane Nicoll
Feb 4 at 9:10
The flag has been deprecated because that behaviour is going away. The last part of my answer mentions how to enable a security context in test.
– Stephane Nicoll
Feb 4 at 9:10
|
show 2 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53389774%2fspring-boot-2-1-webmvctest-without-spring-security-auto-configuration%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown