You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2019/10/28 13:53:51 UTC
Clarify why surefire filters tests (*Test/Test*)
Hi everyone,
Today a colleague asked me why "FooWhateverBla" test was not executed with
maven whereas it works well in Intellij.
Indeed I explained him Surefire does its own scanning and the hardcoded
defaults but I actually wonder why we still do that and if it is not just
something inherited from early times.
Concretely, scanning target/test-classes we can find all @[whatever
package]Test (and meta @Test), subclasses of Specification or whatever
parent etc. In other words the scanning can default to the supported
providers (any other pattern is useless since it will not run anyway) and
we can even just delegate the scanning to the underlying engine in a lot of
cases.
The gain is to drop code in surefire but also expose something more user
friendly (aligned on the used engine).
Any rational I'm missing to still have an abstraction there?
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>
Re: Clarify why surefire filters tests (*Test/Test*)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
This is often the convention I use but it looks going against what we run.
Engines come with a convention so we don't need to add yet another one IMHO.
Or the corrolar would be we should warn the user he did something useless
at least - which means doing the same work than supporting any convention
by default - since we only speak about defaults here.
I have no blocker or urgent need but that is something we should put on the
4.x (5.x?) list since we should clearly simplify testing integrations IMHO.
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 lun. 28 oct. 2019 à 17:24, John Patrick <nh...@gmail.com> a
écrit :
> I would argue the opposite, maven/surefire gives you configuration and
> control over what to files to look at for tests, and potentially what
> files to ignore/exclude.
>
> IntelliJ is just a blunder bust for searching '*', but yes might be
> seamed as more user friendly.
>
> For some projects I've both surefire unit tests and failsafe
> integration tests in 'src/test/java', but IntelliJ just executes both
> and so often the integration tests fail as I've not setup the pre
> reqs.
>
> In large code bases it good to have tests within files names including
> the word 'Test' as you might have other helper utils/classes also
> within 'src/test/java' that support those tests. So when searching or
> navigating the codebase you know which are which.
>
> On Mon, 28 Oct 2019 at 13:54, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > Hi everyone,
> >
> > Today a colleague asked me why "FooWhateverBla" test was not executed
> with
> > maven whereas it works well in Intellij.
> >
> > Indeed I explained him Surefire does its own scanning and the hardcoded
> > defaults but I actually wonder why we still do that and if it is not just
> > something inherited from early times.
> >
> > Concretely, scanning target/test-classes we can find all @[whatever
> > package]Test (and meta @Test), subclasses of Specification or whatever
> > parent etc. In other words the scanning can default to the supported
> > providers (any other pattern is useless since it will not run anyway) and
> > we can even just delegate the scanning to the underlying engine in a lot
> of
> > cases.
> > The gain is to drop code in surefire but also expose something more user
> > friendly (aligned on the used engine).
> >
> > Any rational I'm missing to still have an abstraction there?
> >
> > 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Clarify why surefire filters tests (*Test/Test*)
Posted by John Patrick <nh...@gmail.com>.
I would argue the opposite, maven/surefire gives you configuration and
control over what to files to look at for tests, and potentially what
files to ignore/exclude.
IntelliJ is just a blunder bust for searching '*', but yes might be
seamed as more user friendly.
For some projects I've both surefire unit tests and failsafe
integration tests in 'src/test/java', but IntelliJ just executes both
and so often the integration tests fail as I've not setup the pre
reqs.
In large code bases it good to have tests within files names including
the word 'Test' as you might have other helper utils/classes also
within 'src/test/java' that support those tests. So when searching or
navigating the codebase you know which are which.
On Mon, 28 Oct 2019 at 13:54, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Hi everyone,
>
> Today a colleague asked me why "FooWhateverBla" test was not executed with
> maven whereas it works well in Intellij.
>
> Indeed I explained him Surefire does its own scanning and the hardcoded
> defaults but I actually wonder why we still do that and if it is not just
> something inherited from early times.
>
> Concretely, scanning target/test-classes we can find all @[whatever
> package]Test (and meta @Test), subclasses of Specification or whatever
> parent etc. In other words the scanning can default to the supported
> providers (any other pattern is useless since it will not run anyway) and
> we can even just delegate the scanning to the underlying engine in a lot of
> cases.
> The gain is to drop code in surefire but also expose something more user
> friendly (aligned on the used engine).
>
> Any rational I'm missing to still have an abstraction there?
>
> 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>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org