<div dir="ltr">Hey Keith,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 6:47 PM, Keith Curtis <span dir="ltr"><<a href="mailto:keithcu@gmail.com" target="_blank">keithcu@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi;<br>
<br>
The C/C++ groups I worked in had all testers working in a scripting<br>
language. Those who had the skills and interest to write in C/C++ moved to<br>
product code. It was easy for developers to debug problems because the test<br>
application allowed you to configure which tests to run, the IDE was easy to<br>
use with single-step debugging, etc. You'd need two debuggers running, but<br>
it worked great and was little slower than working with C++ tests.<br></blockquote><div><br></div><div>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.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In the situation here, I agree that unit tests should be in C++, typically<br>
written by the developers when they write their code. However, there can<br>
still be room for further testing in Python. I've seen code that would call<br>
random APIs with random values and via genetic algorithms would come up with<br>
good ways to stress and crash the product. It would find plenty of bugs that<br>
no unit test ever could. The test harness was very good, it only reported<br>
problems that were reproducible, and the app would narrow it down to the<br>
shortest number of steps. So perhaps it is good to figure out whether<br>
something is a unit test, a UNO test, or some other fancier kind of testing.<br>
If a developer doesn't want to run Python, they can just look at the stack<br>
trace and try to figure it out on their own similar to what happens when<br>
bugs are reported today. Python just makes it more reproducible.<br></blockquote><div><br></div><div>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).<br>
<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It also seems that people who are interested in Python today could work on<br>
making it easier to contribute to LibreOffice in Python. There is a small<br>
community of Python hackers contributing to today, mostly it seems it is<br>
just Xisco Fauli. You don't need to re-write the whole app in Python to<br>
bring in new people, as there are already plenty of places to contribute,<br>
especially if you consider Base ;-) I find more and more programmers who<br>
don't have C++ experience, meanwhile Python is one of the fastest growing<br>
languages.<br>
<br></blockquote></div><br></div><div class="gmail_extra">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.<br>
<br></div><div class="gmail_extra">Regards,<br>Markus<br></div></div>