I like the idea, personally. I was toying with the idea of also have a target for fuzz testing stuff. So that could be done at the same time too!
-- Marc-André Laverdière Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India On Tue 20 Sep 2011 02:57:26 PM IST, Markus Mohrhard wrote: > Hello all, > > 2011/9/20 Caolán McNamara <caol...@redhat.com <mailto:caol...@redhat.com>> > > On Mon, 2011-09-19 at 21:18 +0200, Bjoern Michaelsen wrote: > > I am proposing introducing a new target in the build system called > > "slowunitcheck". Those are tests that are technically unittests (need > > no full install), but considered to slow/longrunning to be run on > every > > build. Instead those are run along the subsequenttests when running > > "make check" (or alone by running "make slowunitcheck"). > > > > Opinions? > > If the goal is to support e.g. calc guys rebuilding fast when hacking > sc, the more natural approach to me would be an extra non-unit-test > module-level target, e.g. cd sc; make skipchecks or some such, an > explicit opt-out-for-this-rebuild rather than out-in. > > I wonder exactly why/where the sc tests are slow, I mean linking the big > test libs is definitely slow, is that the critical part of the > slowdown ? Or is it running the tests ? > > I'd kind of expect that linking the test would take the vast majority of > time, if that's the case then for meaningful speedup the creation of the > test would need to be skipped as well as the execution ? > > > The sc unit tests are slow because we use the filter-tests as an way to > test not only the import but also the first recalculation. We havenow > already about 10 files that we import and check and I have some > additional that are not yet finished. Then I'm working at the moment on > an similar approach to test vba code in sc. The problem with all these > tests is that most of them are only relevant for certain cases and I > think for example the bugFix files don't need to be executed by everyone. > > I personally don't see the problem with calc devs here, but that as soon > as they get slower and other people complain about them they might > consider to skip all tests. So I prefer that everyone executes at least > a basic set of tests during every build than someone skipping all tests > because some special tests are too slow. > > Regards, > Markus > > > _______________________________________________ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
