fdo#55814: unit test is missing

[Miklos Vajna]

Hi David,

On Thu, Mar 21, 2013 at 10:42:27AM +0100, David Ostrovsky <d.ostrovsky at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20130322/17377833/attachment.pgp>