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 <nhoj.patr...@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 <rmannibu...@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-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
