Good point so guess it can be combined with a config (more a system properties) to run in memory or forked and therefore the fs can be either in mem or just populated from the spec (annotations). Was looking to get something more fluent on the full setup than matching multiple resources which is - at least for me - a but bothering and looks old school.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 30 oct. 2019 à 15:23, Stephen Connolly < [email protected]> a écrit : > On Tue, 29 Oct 2019 at 22:16, Romain Manni-Bucau <[email protected]> > wrote: > > > 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 > > > That would prevent the tests from running Maven in a different JVM... Not > sure if the JUnit extension supports that, but knowing the libraries likely > used I suspect it does > > > > > > > > > > > > > > [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 > > > > > >
