On Thu, Apr 04, 2013 at 09:37:51AM +0200, Noel Grandin wrote:
Yes, it is probably true that you can not easily debug these unit tests.
But is the debuggability the only argument here? I doubt it. We have
Yes it very much is. I'm currently struggling with visibility into a
failing unit test, and the dual Java/C++ nature of the unit test
makes it incredibly hard for me to find the source of the problem.
Well, IMHO the main problem with the unoapi tests wrt this is that they
'centralized' a lot of the expectations on the UNO-Api -- which made them hard
to quickly rewrite in C++. THe complex tests should not have this issue.
Other than that, IMHO this is mostly a false dilemma -- not everyone who might
write Python tests would write C++ tests. If this leads to more reliable tests
of any kind, which will turn into tests of the C++ kind when they first fail,
Im all for it.
A side issue: As I wrote in:
http://skyfromme.wordpress.com/2013/03/19/autopkgtests-for-adults/
I enabled running the (Java) tests against a version installed into the system
-- which is better than testing against a version not into the system, so I
would love to keep that ability when we get more C++ tests (for Python tests I
assume that to be trivial).
@moggi: As I havent looked into that yet -- would you see any blockers there?
Best,
Bjoern
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.