Le mar. 29 oct. 2019 à 22:58, Karl Heinz Marbaise <khmarba...@gmx.de> 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
