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


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 <caolanm@redhat.com <mailto:caolanm@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

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.