got it thank you i see what you're saying. I thought that maybe ReactorTestBuildCustomizer would be included under intiailizr-generator-spring for webflux.
Would some of the additional testing features part of io.projectreactor:reactor-test be included in spring-boot-starter-test' in the future? I suppose this question is better suited for the Spring Boot Gitter conversation
spring-boot-starter-test really has to focus on what’s generally useful
ReactorTestBuildCustomizer I got you from the start. I agree there is a fine line between things in generator-test and things in start.spring.io. The key thing to remember is that the library does not know anything about particular dependencies. And the reactor id is defined in the service, not the library. For that reason alone, we can’t move the implementation there
Hello again, I was wondering if there were thoughts to add a @ConditionalOnDependencyGroup annotation? As an example, I would like to always include a BOM(ie. implementation platform('org.testcontainers:testcontainers-bom:1.14.3')) for databases supported by my Initializr
Would this be the right approach or is there something that I may be missing? Thank you
If you could set a facet for all dependencies in a group that would give you what you need, isn’t it?
Yes that would work as well! But I think for my case, since I'm not spanning across multiple dependency groups at the moment it may be too much.
conditional-on-facet example here -> https://github.com/xenit-eu/start.xenit.eu/blob/master/initializr-generator/src/main/java/eu/xenit/alfred/initializr/generator/condition/OnRequestedFacetCondition.java
Thank you Toon Geens, I think this is cool. Maybe facets can be part of the ProjectDescription? But that feels weird as well.. Just thinking out loud. I see how retrieving the metadata is less than ideal since it pertains to the Initializr rather than to project generation. Please correct me if I'm wrong
I think what I may be having trouble grasping is when are conditionals appropriate versus having checks in a Customizer
Dependency for the purpose of the project generation and a Dependency with metadata element. Ideally, you should have access to the latter from the former.
@ConditionalOnDependencyGroup idea you had doesn’t work either then? I am confused
InitializrMetadata class????)
ProjectRequest and ProjectDescription instead? I haven't done this personally but maybe this can help: https://docs.spring.io/initializr/docs/current/reference/html/#create-instance-advanced-config-custom-project-request
Hello again, I was looking at the initializr-generator-test and I was wondering what are some use cases where I would want to use the ProjectAssetTester instead of the ProjectGeneratorTester? Is it only when I'm generating anything that does not involve @ProjectGenerationConfiguration annotated classes?
Also, out of curiosity, how come @SpringBootTest was avoided for testing project generation? I initially started there and was referencing https://github.com/spring-io/start.spring.io/blob/master/start-site/src/test/java/io/spring/start/site/extension/AbstractExtensionTests.java before I noticed there was an initializr-generator-test module.
Thank you
ProjectAssertTester is more fine grained, see Javadoc. It lets you pick up indivudal contributors and make sure they behave as you expect. ProjectGeneratorTester is the full thing and it detects all available contributors which is not something you may want when testing individual components
@SpringBootTest shouldn’t be used. I should confess that AbstractExtensionTests is not ideal and should be reviewed at some point. We’re making sure that the correct behaviour is observed when all contributions are available. Soe more focused tests would be interesting in that module.
initializr-generator-spring, I found I needed to bring in almost everything to get a test to run to the point I thought my test may as well be an integration test with @SpringBootTest. Example setup I currently have: ProjectGeneratorTester projectGeneratorTester = new ProjectGeneratorTester()
.withBean(InitializrMetadata.class,
() -> InitializrMetadataTestBuilder.withDefaults().build())
.withConfiguration(InitializrConfiguration.class)
.withIndentingWriterFactory()
.withDirectory(directory);I think I'm missing something again... I would like to allow only certain dependencies depending on project type. Or another option is to prevent someone from selecting multiple dependencies from a dependency group. I feel like the first option seems to make more sense.
Is the proper way to do this to add logic to the InitializrMetadataUpdateStrategy? or should I even be doing something like this? I would like applications to only follow one paradigm instead of multiple
After thinking some more about my second question, ProjectGeneratorTester and ProjectAssetTester make sense to test interaction between components. As far as integration tests go though, what would be a preferred method? Possibly making a MockMvc or RestTemplate call to /starters.zip? I do see some useful methods here: https://github.com/spring-io/initializr/blob/master/initializr-web/src/test/java/io/spring/initializr/web/AbstractInitializrIntegrationTests.java
Would it make sense to leverage some of the utility methods from AbstractInitializrIntegrationTests.java?
implementation 'org.springframework.boot:spring-boot-starter-data-r2dbc'
implementation 'org.springframework.boot:spring-boot-starter-webflux'
runtimeOnly 'dev.miku:r2dbc-mysql'
runtimeOnly 'mysql:mysql-connector-java'
Error:
java.lang.NoSuchMethodError: reactor.netty.http.server.HttpServer.runOn(Lreactor/netty/resources/LoopResources;)
I don’t understand why you’d need to call
/starter.zip. You don’t need to test the library in your own code
I agree with not needing to test libraries. I suppose if that is the case then integration tests are unnecessary and tests leveraging ProjectGeneratorTester and ProjectAssetTester are sufficient.. I think that makes sense