snicoll on new-generator
Adapt to latest API change Move InitializrDefaultStarterBu… (compare)
snicoll on new-generator
Switch project structure to use… (compare)
snicoll on master
Upgrade to JUnit 5.4.0-RC1 Split metadata specific excepti… (compare)
snicoll on master
Initiate 0.8.0.BUILD-SNAPSHOT v… (compare)
mbhave on new-generator
Adapt tests to use new API Customize build version based o… (compare)
mbhave on master
Fix generate release notes scri… (compare)
got it thank you i see what you're saying. I thought that maybe
ReactorTestBuildCustomizer would be included under
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-testreally has to focus on what’s generally useful
ReactorTestBuildCustomizerI got you from the start. I agree there is a fine line between things in
generator-testand things in
start.spring.io. The key thing to remember is that the library does not know anything about particular dependencies. And the
reactorid 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
Dependencyfor the purpose of the project generation and a
Dependencywith metadata element. Ideally, you should have access to the latter from the former.
@ConditionalOnDependencyGroupidea you had doesn’t work either then? I am confused
ProjectDescriptioninstead? 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
ProjectAssertTesteris more fine grained, see Javadoc. It lets you pick up indivudal contributors and make sure they behave as you expect.
ProjectGeneratorTesteris the full thing and it detects all available contributors which is not something you may want when testing individual components
@SpringBootTestshouldn’t be used. I should confess that
AbstractExtensionTestsis 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,
ProjectAssetTester make sense to test interaction between components. As far as integration tests go though, what would be a preferred method? Possibly making a
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
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
ProjectAssetTester are sufficient.. I think that makes sense