Re: Testing/Working on PyUNO?

Hey Keith,


On Wed, Feb 19, 2014 at 6:47 PM, Keith Curtis <keithcu@gmail.com> wrote:

> Hi;
>
> The C/C++ groups I worked in had all testers working in a scripting
> language. Those who had the skills and interest to write in C/C++ moved to
> product code. It was easy for developers to debug problems because the test
> application allowed you to configure which tests to run, the IDE was easy
> to
> use with single-step debugging, etc. You'd need two debuggers running, but
> it worked great and was little slower than working with C++ tests.

So we are not really discussing about python tests in general. I'm sorry if
that was the impression. For out-of-process tests python tests are arguably
the best choice. It is however much more complicated when it comes to
in-process tests. We already use out-of-process python tests like the crash
testing or convwatch. The whole discussion was mostly where python tests
make sense in our build as in-process tests.


> In the situation here, I agree that unit tests should be in C++, typically
> written by the developers when they write their code. However, there can
> still be room for further testing in Python. I've seen code that would call
> random APIs with random values and via genetic algorithms would come up
> with
> good ways to stress and crash the product. It would find plenty of bugs
> that
> no unit test ever could. The test harness was very good, it only reported
> problems that were reproducible, and the app would narrow it down to the
> shortest number of steps. So perhaps it is good to figure out whether
> something is a unit test, a UNO test, or some other fancier kind of
> testing.
> If a developer doesn't want to run Python, they can just look at the stack
> trace and try to figure it out on their own similar to what happens when
> bugs are reported today. Python just makes it more reproducible.

So for UNO it makes sense to use python instead of our current java tests
(I still would prefer C++ as it is easier to debug but python already
allows in-process tests). However calling something through UNO or in the
UI often takes different code paths. That means if a test through the API
fails you can't just try to reproduce it in the UI and see if you can debug
it there. On the other hand looking at the API documentation and writing a
test FOR the API can be done perfectly find in python (with the exception
that is still a bit more difficult to debug).



> It also seems that people who are interested in Python today could work on
> making it easier to contribute to LibreOffice in Python. There is a small
> community of Python hackers contributing to today, mostly it seems it is
> just Xisco Fauli. You don't need to re-write the whole app in Python to
> bring in new people, as there are already plenty of places to contribute,
> especially if you consider Base ;-) I find more and more programmers who
> don't have C++ experience, meanwhile Python is one of the fastest growing
> languages.
I mostly agree. IMO we have many tasks perfectly in the scope of python
scripting where python is the best tool for the job. So it is not like the
project does not value great python developers and if there are people out
there who only know python and want to contribute we are not short of nice
and important tasks.

Regards,
Markus