On 09/19/2011 09:18 PM, Bjoern Michaelsen wrote:
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?
I'm somewhat undecided. While there may be a pragmatic need to exclude from constantly building those unit tests that are too slow, offering a framework for that might make people choose the easy way out, instead of putting work into their slow unit tests to make them fast. (I do not know what makes those sc unit tests slow, so I do not know whether lack-of-trying-to-improve applies here. Just a general concern. And I do know that we already have a framework for fucked up and slow subsequenttests, but I would like to get rid of that over time, replacing them with true unit tests.)
In general, people may want to consult the literature on what to do about slow unit tests, e.g., the section on "Slow Tests" (p. 253ff) in Gerard Meszaros' "xUnit Test Patterns: Refactoring Test Code" (A-W, 2007).
-Stephan _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
