yet another unit test framework? -- was fdo#55814: unit test is missing

[Moving this discussion to ML to have better visibility]

with https://gerrit.libreoffice.org/#/c/3128/ we have support for unit
tests written in python. (We have even found two bugs with it
already ... and fixed).

I am not going to provide the huge advantages of dynamic type languages
in general here, but while python is very impressive it *is* truly
read-write language compare to number of write-only languages, that used
in LO ecosystem.

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
logging framework and in the end one can still migrate python unit test
to C++ (if needed) to debug it.

Thanks
David 

On Fri, 2013-03-22 at 10:58 +0100, Miklos Vajna wrote:
> 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
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice