Re: Clarify why surefire filters tests (*Test/Test*)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Clarify why surefire filters tests (*Test/Test*)

John Patrick
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Clarify why surefire filters tests (*Test/Test*)

Romain Manni-Bucau
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 <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>