Re: Testing/Working on PyUNO?

Hi Markus,

Thanks for the explanation. I've recently been talking to lots of
younger programmers and so wanted to write a few words.

It is a conundrum to me why you have a quite large C++ team, but not
many people supplementing and polishing in Python, especially given
they should be easier to find. They are out there!

Regards,

-Keith




On Wed, Feb 19, 2014 at 6:50 PM, Markus Mohrhard
<markus.mohrhard@googlemail.com> wrote:
> 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