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


Hi David,

On Thu, Mar 21, 2013 at 10:42:27AM +0100, David Ostrovsky <d.ostrovsky@idaia.de> wrote:
And yes i am going to migrate it to C++ as you argued that it would be
easier to debug then java. I wonder if it would make sense to establish
Python_test machinery in our build system to be able to write such and
many other tests in python instead and just say make Pytest_sw_complex
instead of make JunitTest_sw_complex (python have got unittest module
that we can start with)?

Hmm, yes, I think that would be an improvement. As far as I understand,
most of the Java tests have two difficulties:

1) A separate soffice process is started, then Java code connects to
this, and executes tests. This is a bit slow, compred to the C++ unit
tests, where we bootstap UNO ourselves + a bit painful to debug, as you
have to run one process in gdb (listening on a socket) and an other
process to trigger the problem.

If do a 1:1 conversion of Java tests to Python, this will be still an
issue. IMHO doing the C++ way for Python (running the tests in a single
process) makes more sense.

(Don't confuse these C++ tests with the various uwriter/ucalc/etc tests,
which even have access to private library symbols.)

2) When a unit test fails, it's handy to step the unit test line-by-line
in gdb to see exactly which line triggers an exception, etc.

I imagine this only works if you write the test in C++, but even with
basic or python, it should not be *that* bad, as we can have the
interpreter with debug symbols, etc. I think in this second case even a
1:1 conversion from java to python would help a lot.

And after all, be sure to talk to Markus, he's the testing expert, not
me. :-)

HTH,

Miklos

Attachment: signature.asc
Description: Digital signature


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.