Improve Gatling integration

[mraible]

Overview of the issue

I think our Gatling integration can be improved, especially for microservices. First of all, we should document how to run it on https://www.jhipster.tech/running-tests as a took me a bit to figure it out.

Step 1: Download Gatling Step 2. Extract it somewhere and add /path/to/gatling/bin to your PATH Step 3. In a terminal, cd into src/test/gatling and run gatling.sh or gatling.bat, depending on your OS

This is the first thing I think we should fix.

Next, I realized that for OAuth architectures, microservices are only resource servers. There's no way to log in to them, you can only access them by sending a valid access token. Currently, when you add Gatling to OAuth microservices, it generates the tests in the microservice project and fails to authenticate.

For this reason, I think we should generate all the Gatling tests in the gateway and adjust paths accordingly (kinda like we do for the UI files). This would have the added benefit of testing the gateway's routing performance.

Motivation for or Use Case

OAuth with Gatling in a microservices environment doesn't currently work.

Reproduce the error

Generate a microservices architecture with the following JDL:

application {
  config {
    baseName gateway
    reactive true
    packageName com.okta.developer.gateway
    applicationType gateway
    authenticationType oauth2
    prodDatabaseType postgresql
    serviceDiscoveryType eureka
    testFrameworks [cypress]
  }
  entities Blog, Post, Tag, Product
}

application {
  config {
    baseName blog
    reactive true
    packageName com.okta.developer.blog
    applicationType microservice
    authenticationType oauth2
    databaseType neo4j
    devDatabaseType neo4j
    prodDatabaseType neo4j
    enableHibernateCache false
    serverPort 8081
    serviceDiscoveryType eureka
    testFrameworks [gatling]
  }
  entities Blog, Post, Tag
}

application {
  config {
    baseName store
    reactive true
    packageName com.okta.developer.store
    applicationType microservice
    authenticationType oauth2
    databaseType mongodb
    devDatabaseType mongodb
    prodDatabaseType mongodb
    enableHibernateCache false
    searchEngine elasticsearch
    serverPort 8082
    serviceDiscoveryType eureka
    testFrameworks [gatling]
  }
  entities Product
}

entity Blog {
  name String required minlength(3),
  handle String required minlength(2)
}

entity Post {
  title String required
  content TextBlob required
  date Instant required
}

entity Tag {
  name String required minlength(2)
}

entity Product {
  title String required,
  price BigDecimal required min(0),
  image ImageBlob
}

relationship ManyToOne {
  Blog{user(login)} to User,
  Post{blog(name)} to Blog
}

relationship ManyToMany {
  Post{tag(name)} to Tag{post}
}

paginate Post, Tag with infinite-scroll
paginate Product with pagination

microservice Product with store
microservice Blog, Post, Tag with blog

After starting everything (including Docker containers), cd into blog/src/test/gatling and run ./gatling.sh. Choose any test and watch it fail to authenticate.

Suggest a Fix

See above.

JHipster Version(s)

Version 7, beta 0

[atomfrede]

Maybe we can also add documentation how to use the gatling gradle/maven plugin. At least the gradle plugin works quite well.

[atomfrede]

Should we move the gatling part to an own subgenerator/blueprint, such that we can compose it in the entity generator when needed? (now it is part of entity server).

EDIT: And it looks like the the gatling test are expecting a keycloak login form. I think we can change this to find the only form on the page so okta should work too.

[mraible]

I think moving Gatling would help. I also think monolith vs microservice could have improvements. With a microservice architecture, it seems like you'd want to test "the whole thing" in addition to each microservice (like the e2e tests do).

[atomfrede]

So I would propose the following:

• monolith, everything works as before
• microservice gateway + gatling generate the entity simulation
• microservice app + gatling generate no simulation(?) to test "the whole thing"?

[atomfrede]

Having a dedicated sub generator would also enable blueprints to overwrite the simulation files (e.g. different cookie naming requirements or so).

[pascalgrimaud]

For your information, this alias could help too: https://github.com/jhipster/jhipster-oh-my-zsh-plugin/blob/main/jhipster.plugin.zsh#L75-L77

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

[atomfrede]

Keep it open. There is already a draft PR

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

[atomfrede]

Keep it open.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

[atomfrede]

Keep it open

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

[atomfrede]

Keep it open

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

[mraible]

I'd still like to see this.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

[atomfrede]

Keep it open

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

[atomfrede]

Keep it open

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

[mraible]

I'm still interested in this. Would a bug bounty help make it happen?

On Wed, Oct 20, 2021 at 18:07 github-actions[bot] @.***> wrote:

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs 😃. Comment or this will be closed in 7 days

—

You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/13390#issuecomment-948125227, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAELZH3ICG4ISADX6H4TWDUH5KS3ANCNFSM4VO2763A .

[atomfrede]

Hope to find some time this weekend too rebase the pr.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

[atomfrede]

Keep it open

[atomfrede]

Hope to find some time before christmas, right now working on another side project. We could also consider switching to java as the gatling language which is now supported (in addition to scala and kotlin). Maybe with that we can provide the gradle/maven plugins again out of box without problems

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

[atomfrede]

Keep it open

[pascalgrimaud]

@atomfrede : I added the label work in progress

[atomfrede]

I plan to pick up this again. Besides the better microservice integration I would like to change the gatling scripts to use java and in turn add the maven/gradle plugins again (as we have removed it because of the need for scala plugin if I remember correctly), such that they can be started with mvn or gradle without the need to install gatling distribution.

WHDYT @mraible @pascalgrimaud ?

[pascalgrimaud]

agree :)

[DanielFran]

@atomfrede can you confirm this can be close since we switch to Gatling's Java dsl?

[atomfrede]

Need to check but I think the original issue was about something else.

[deepu105]

@atomfrede do you plan to finish this?

[atomfrede]

It is still a good thing to do. Not sure I find time to do much this year.