Hi In case I'm stating the obvious, I think there's an elephant in the room.
Could we try to make the slow tests faster? If the indeed sleep a lot, maybe there are ways around that. IMHO sleeping tests also have the tendency to fail "randomly", i.e. are not deterministic. So a side-benefit *could* be more stable builds? Regards Julian On Fri, Mar 11, 2016 at 11:20 AM, Stefan Egli <[email protected]> wrote: > Hi, > > On 11/03/16 10:37, "Oliver Lietz" <[email protected]> wrote: > >>On Friday 11 March 2016 10:19:13 Bertrand Delacretaz wrote: >>> >>> >>> Do we agree that this second category is bad? >>> >>> I suppose the result is that people rarely or never run a full build >>> with tests - IMO the full build should be coffee break compatible, so >>> around 10-15 minutes. >>> >>> I haven't looked in detail yet at the second category above, does >>> someone familiar with those tests have suggestions? >>> Reduce the number of iterations unless a specific Maven profile is >>>active? >>> Create a JUnit SlowTests category? >> >>are these slow tests really unit tests or integration tests? We already >>have a >>profile integrationTests which could be used to run (more) slow tests. >>IMHO we should stop doing full builds and only build modules which have >>changed. > > Speaking for the largest chunk of time consumed - my discovery tests - > those are probably more unit tests like. > > But yes, they should probably be in a 'slow' category of tests to avoid > consuming time of ppl. Even if that'll mean they will not be run by most > as few would volunteer to run the slow tests. > > So if we agree on how to categorize them as slow I can look into > extracting a useful part as normal and the rest as slow. > > Cheers, > Stefan > >
