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
