[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: policy around "slow-running tests"



On 2019-08-27 02:20, Paul Gevers wrote:

In the case of dolfin, again for example, tests cover not only unit
tests but also run demo scripts. Most of the test time is in the demos,
which take about 15 min each full set, run 4 times over [C++,
python]×[serial, mpi] making an hour in total demo time.    It would be simple enough to run a subset of demos if we considered it important to
reduce total test time.demo_hyperelasticity_serial

Until a huge amount of packages start to have very long running tests,
this is not a problem. Please be advised that spreading your tests
around multiple stanza in d/t/control even circumvents the 2:47h
timeout, as that timeout is *per* autopkgtest.


Thanks Paul. Sounds like it should be safe to let dolfin run through its tests and demos.

Certain individual demos (demo_hyperelasticity_serial, demo_elastodynamics_mpi) would be first in line to chop, but even then they're less than 5 min each.

Actually, looking more closely, it's the python unit tests taking up the larger time (1500s each for serial and mpi, so 50 min total in python unittests).

We might drop demos but we probably don't want to drop python unittests. So I'll leave all the tests running as they are for now.

Drew


Reply to: