Hi everyone,
Yesterday I needed to test a maven plugin around graal so wrote a junit5
extension relying on testcontainers. Think it is close to this thread so
sharing the idea/code:
https://gitbox.apache.org/repos/asf?p=geronimo-arthur.git;a=blob;f=integration-test/src/test/java/org/apache/geronim
am, programming language is our toy ;-)
everybody has some preferences, so i respect them and i understand that
even the Lambda would be a big jump for us nevertheless the Groovy or
Kotlin.
i saw the parameterized tests, re-runs in Groovy, log result of assertion
statements, and I spoke with Benedi
Karl>on the language features but since JDK8 I don't see any advantage
What about Kotlin?
There are nice things there: the language is statically compiled, great
Java interop, there are extension functions, multiline strings, helpful
standard library, default parameters.
Kotlin is great for creat
Integration test choices include the excellent Spock as mentioned. I've
used it and it's very solid. Two more choices include:
Another choice is Cuppa - https://github.com/cuppa-framework/cuppa
I've used this too, and it's great - no right-click-run-this-one in
Intellij though. I wish it had more
Oops. Blog entry linking to video of 16s build -
https://paulhammant.com/2017/02/05/a-16-second-java-webapp-build-including-webdriver-tests/
Karl
(Sorry for top posting)
Thank you very much for moving this forward.
In my personal experience one real blocker in contributions to Maven,
expecially plugins, is to write integration tests.
So having a nice way to create tests is very welcome.
Having a way to run tests as simple unit tests fro
Hi,
let me conclude some of the things together:
The decision which I have made against Spock was based on several
reasons:
* People often tend to write Java code (which is valid), cause
they don't know Groovy or don't want to learn a new language
just to write tests.
This means in th
Not sure I understand it well Tibor, do you encourage to multiply the
number of potential solutions to request more time to contributor to see
how to do things?
Don't think it is good, a single simple solution sounds more promising -
once again from my past experience.
Once again Tibor, all I'm wr
Romain, the Java has not made any significant progress in language after
Java 9. Yes, some JVM features in J13 were really great but not in language.
All fixes about switch-case in several versions, strings, preliminary
feature. Nothing very progressive for developers! And I think the frequent
rele
@Tibor: do you agree we write the tests with chai (js)? It is the same to
use groovy for a java dev today since java caught up its lateness. Not
stacking layers and avoiding useless abstractions is the best way to enable
people to contribute from my experience. As soon as you add a layer which
has
Romain, I am glad that you are with me.
Attracting the contributors!
I hope we all voted for Java 8 sources in Maven Core.
And Spock is the same story.
Java is the like C++ old style.
Lambda makes this language more moderns a bit.
Regarding issues with Java 14, all can be fixed, just give the Sp
@Tibor: one goal we should focus on on any new feature is to enable us to
attract more new contributors, spock has the disadvantage to not be
mainstream at all + to be on groovy which has some issues to support recent
java version so it will not help it to be more adopted, therefore I guess
jupiter
Hi,
On 30.10.19 15:23, Stephen Connolly wrote:
On Tue, 29 Oct 2019 at 22:16, Romain Manni-Bucau
wrote:
Le mar. 29 oct. 2019 à 22:58, Karl Heinz Marbaise 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 probabl
Karl, where you define CLI command in each test?
Regarding the f/w you have selected. If I had to decide between JUnit5 or
Groovy/Spock, I would decide for Spock.
On Tue, Oct 29, 2019 at 9:47 PM Karl Heinz Marbaise
wrote:
> Hi to all,
>
> I've invested some time to get a thing working in a diffe
well, you have use different JVMs if you expect different env vars.
On Wed, Oct 30, 2019 at 3:23 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> On Tue, 29 Oct 2019 at 22:16, Romain Manni-Bucau
> wrote:
>
> > Le mar. 29 oct. 2019 à 22:58, Karl Heinz Marbaise a
> > écrit :
> >
>
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 -
On Tue, 29 Oct 2019 at 22:16, Romain Manni-Bucau
wrote:
> Le mar. 29 oct. 2019 à 22:58, Karl Heinz Marbaise 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
Le mar. 29 oct. 2019 à 22:58, Karl Heinz Marbaise 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 glob
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 (
Hi Karl
Not sure id do a MavenIT annotation - test is enough probably - but i like
jupiter style.
Im less exited by assertj but it is probably a habit thing.
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? Goal would
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 co
21 matches
Mail list logo
