Le mar. 29 oct. 2019 à 22:58, Karl Heinz Marbaise <[email protected]> a écrit :
> Hi Romain, > > On 29.10.19 22:40, Romain Manni-Bucau wrote: > > Hi Karl > > > > Not sure id do a MavenIT annotation - test is enough probably - but i > > like jupiter style. > > MavenIT[1] annotation contains more information like global/local cache, > the default goals which are used for the build, debugging or not (just > to mention some; I think there will be more). > > Also so the MavenTest annotation is needed to define specific things for > Maven like activeProfiles etc. > > [1]: > > https://github.com/khmarbaise/maven-it-extension/blob/master/src/main/java/org/apache/maven/jupiter/extension/MavenIT.java > > See also: > > > https://github.com/khmarbaise/maven-it-extension/blob/master/src/test/java/org/apache/maven/jupiter/it/MavenIntegrationIT.java You can alias @MavenTest for that no? This is what i had in mind. Like @ShadeTest decorated with @MavenTest to set defaults. So you reduce thz number of annotations. That said it is not a blocker. > > > > > > Im less exited by assertj but it is probably a habit thing. > > I'm not sure if I see your issue with AssertJ. Have you used it? AssertJ > brings clear expression and readable tests in general and gives me a > simple way to create custom assertions to support special parts for a > Maven build like Log file, project structure, target directory contents, > content of archive files etc. ? > > like this: > > assertThat(result) > .project() > .hasTarget() > .withEarFile() > .containsOnlyOnce("META-INF/MANIFEST.MF"); > > I've never seen a assertion framework which makes it possible to write > tests in a more or less fluent way ... > I did use it a few and dropped it since it does not bring much i most cases. Asserts stay simple and chaining them just hit autoformatting limitations in general. Also assertj had some dependency conflicts - fixed now IIRC. So staying minimal was good. The side note being: do you need it or can you back your dsl with jupiter assertions? No strong need ;). > What would be your choice? > Just an available model, fluent if you want, but no additional dep. Default Assertions is enough for most cases, in particular with streams and lambdas. > > > > > Wonder if you evaluated to run in a fake filesystem like jimfs or so and > > enable the pom+files to be defined on the test method? > > This is exactly where I have decided against at the moment cause > construction of a full maven project with all it's pom file(s) > directories source code etc. is based on the things I want to solve to > complicated...we already have such things[2] also in plexus testcase you > can do such things or more easier today just use mockito ... > Hmm, this is not comparable. Mockito is like not writing tests, jimfs is launching a real build on a fake in memory filesystem, no mocking for maven. > Currently I have gone the path to have a convention where to find the > projects which are used to be tested like maven-invoker-plugin already > does ...and can also being executed manually within the directory > without any change ...helps a lot in case error hunting ... > > Can you explain the hint about fake filesystem like jimfs a little bit > more cause I don't know jimfs etc. and what you have in mind? > Jimfs is a FileSystem implementation so if maven uses java.nio.file api then we can run on an in memory FS and configure it from any metamodel we want. It would be close to this sftp testing api https://github.com/rmannibucau/rule-them-all/blob/master/src/test/java/com/github/rmannibucau/rules/test/sftp/TestSftpRule.java#L32 > > [2]: > > https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/index.html > > > > Goal would be to > > not split setup and asserts (given and then colocalized, then being the > > mvn exec). > > Maybe I misunderstand that? Can you give an example ? > > Kind regards > Karl Heinz Marbaise > > > > > > Hope it makes sense. > > > > > > Le mar. 29 oct. 2019 à 21:47, Karl Heinz Marbaise <[email protected] > > <mailto:[email protected]>> a écrit : > > > > Hi to all, > > > > I've invested some time to get a thing working in a different way > which > > nags me for a long time. > > > > Integration tests for maven plugins and for maven core... > > > > So created a prototype based on a JUnit Jupiter extension. > > > > The following is the JUnit Jupiter extension (currently very hacky > code; > > not intended to win a competition for good code!) > > > > https://github.com/khmarbaise/maven-it-extension > > > > which contains some documentation which is of course not ready yet... > > but the implementation and usage (see maven-ear-plugin) gives me at > the > > moment already a very good impression how easy it can be to write > > integration tests for a maven plugin etc. > > > > Example from the docs(not 100% working like that yet): > > > > @MavenIT > > class FirstMavenIT { > > > > @MavenTest > > void the_first_test_case(MavenProjectResult result) { > > assertThat(result) > > .build() > > .isSuccessful() > > .and() > > .project() > > .hasTarget() > > .withEarFile() > > .containsOnlyOnce("META-INF/MANIFEST.MF") > > .log() > > .info().contains("Writing data to file") > > .cache() > > .withEarFile("G:A:V") > > .withPomFile("G:A:V") > > .withMetadata().contains("xxx"); > > } > > } > > > > > > I created a branch "maven-it-extension" on Maven EAR Plugin which > shows > > that it can be used in combination with maven-invoker-plugin:install > > goal and using maven-failsafe-plugin to run the tests for > > maven-ear-plugin (some of them at the moment. Not migrated all of > > them yet). > > > > Example which already works: > > > https://github.com/apache/maven-ear-plugin/blob/maven-it-extension/src/test/java/org/apache/maven/plugins/ear/it/EARIT.java > > > > > > WDYT ? > > > > Kind regards > > Karl Heinz Marbaise >
