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,3722022
3,3722022
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@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 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
add a comment |
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@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 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
add a comment |
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@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 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
add a comment |
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
20k45256
20k45256
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 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
add a comment |
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 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
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
add a comment |
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