Generator-jhipster: Use Spring Security test support in REST resource tests

[codecholeric]

Overview of the feature request

I was wondering, why you don't use Spring Security testing support for your REST resource integration tests, but instead bypass the Spring proxy by manually constructing the resource.

E.g. in UserResourceIT the line

@BeforeEach
public void setup() {
    UserResource userResource = new UserResource(userService, userRepository, mailService);
    // ...
}

instead of just using

@Autowired
UserResource userResource;

and then something like

@Test
@Transactional
@WithMockUser(roles = {"ADMIN"})
public void createUser() throws Exception {
    // ...
}

Motivation for or Use Case

It would be closer to the real setup, it would be possible to test permissions as well, and it would need less boiler plate, since you wouldn't necessarily have to inject all dependencies and manually construct the resource.

I would be happy to contribute a PR changing this, but I wanted to ask first, if you had any reason to do it like this?

• [x] Checking this box is mandatory (this is just to show you read everything)

[atomfrede]

I can't remember any specific reason and looking at the code I would say using @WithMockUser seems like the better solution indeed

[codecholeric]

So I guess I'll create a PR then changing this, if there are no arguments against it :smiley:

[atomfrede]

Please go ahead, it will make our generated code easier to understand :+1:

[qmonmert]

@pascalgrimaud I began to work on this feature #11047

[codecholeric]

@qmonmert I know I'm late on this (didn't find the time up to Christmas), but we should definitely align on that! I've already changed many files, my problems are only, that there is such a combinatoric explosion with reactive vs non-reactive and all the options.
You can check out my current state here:
https://github.com/jhipster/generator-jhipster/pull/11050

[codecholeric]

I would also want to gather some feedback though, if the infrastructure setup is easy to understand like that.

[qmonmert]

@codecholeric ah ok no problem

[codecholeric]

I also have one problem, that the DomainUserDetailsServiceIT fails if the 2nd level cache is selected, because the cache section would be closed, and I don't know how it is connected to my changes :thinking:
Anyway, it will still take some time to test due to the vast possibilities of configuration... I only tested one simple case so far, that it really works (and considering the CI, there is much more testing necessary :wink:)
But I do really plan on finishing this over the holidays now :wink: (sucks that there is so much more work out there than hours of free time :disappointed:)

[pascalgrimaud]

@codecholeric : since your PR https://github.com/jhipster/generator-jhipster/pull/11050
the config nodatabase (jwt and session) didn't pass. It works for OAuth2.
Can you have a look plz ?
See https://dev.azure.com/hipster-labs/jhipster-daily-builds/_build?definitionId=23&_a=summary

[codecholeric]

@pascalgrimaud sorry, I was sick. Is this problem solved meanwhile? If my PR was / is the cause, how can it be that all test jobs were green? Is there some config missing from the test jobs?

[pascalgrimaud]

@codecholeric : no worry, it should already be fixed by https://github.com/jhipster/generator-jhipster/pull/11381

Then, in our main generator-jhipster, we can't test all configurations, as there are too much.
So we used another project for testing more config:
https://github.com/hipster-labs/jhipster-daily-builds

This project detected this problem.

[mraible]

Could the fix for this issue be the cause of the failing AccountResourceIT and UserResourceIT tests in my Spring Cloud Gateway PR? I tried re-enabling the tests a few hours ago and they still fail.

[pascalgrimaud]

@mraible : using your links, I saw all the tests pass, no fail.

[mraible]

@pascalgrimaud Yes, the current tests are passing. However, if you look at the last few runs (at the bottom), you'll notice failures when I tried to re-enable tests. I'll merge from master and try again today.