Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


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



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.