On Wed, Feb 19, 2014 at 05:57:26PM +0100, Markus Mohrhard wrote:
1) test core functionality with implementation details but that will rely
on implementation details and will bit rot if you don't execute them
2) test our stable API but then you should not try to avoid implementation
details which means you can't test most bugs
From what I see only point 2 makes sense for python tests especially if you
want to run them only before releases and don't make them fail the build.
Right, I want 2 as it still can help for a lot of issues. How should 1 even
work via PyUNO (which isnt exposing implementation details?).
The idea is essentially even if we 'only' cover the stable API, we can trigger
a _lot_ of code paths like that. And that can be helpful on its own.
Best,
Bjoern
Context
- Re: Testing/Working on PyUNO? (continued)
Re: Testing/Working on PyUNO? · Kevin Hunter Kesling
Re: Testing/Working on PyUNO? · Markus Mohrhard
Re: Testing/Working on PyUNO? · Kohei Yoshida
Re: Testing/Working on PyUNO? · James Michael DuPont
Re: Testing/Working on PyUNO? · Stephan Bergmann
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.