Hi all, we now have a good systematic set of test targets with "unitcheck", "subsequentcheck" and "check" on master(*). However, we now have so many unittests (which is good) that running each and everyone on every build slows down the development cycle esp. in sc -- just because they taking unittesting serious. Now we: a) dont want developers to be punished for writing unittests with slow turnarounds (they might stop writing them) b) dont want people to disable all in-build unittests to be run on every compile (because it is far too easy to forget to run them again once before pushing then)
so 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? Best, Bjoern (*) see http://wiki.documentfoundation.org/Development/buildsystemtargets for details -- https://launchpad.net/~bjoern-michaelsen _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
