Hi,
On Thu, Apr 04, 2013 at 11:00:17AM +0200, Noel Grandin wrote:
On 2013-04-04 10:53, Bjoern Michaelsen wrote:
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++.
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.
These two statements are mutually contradictory. Either Java/Python
unit tests are easy to convert to C++, or they are not, you can't
have it both ways :-)
No: The unoapi tests are hard to convert (not because of them being in Java,
but because of the qadevOOo framework needing a C++ equivalent), the complex
tests are not.
Besides, LO is a C++ program - if you can already code in C++, why
would you want to switch to a different language to write a unit
test?
Because there are people willing to write Python tests but unable (or unwilling
to invest the time) to write C++ tests?
I dont see that as a problem. A reliable test should succeed almost always --
and in that case it doesnt matter in what language it is written in. If it
fails, its probably well worth the time to reimplement it in C++ proper.
But I see little reason to dogmatically write all tests in C++ as:
- more people can write tests in Python
- there are tests that might never fail (and hopefully they are the majority)
and the language they are written in does not matter at all in that case
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.