[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.ostrov...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
