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