Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.