I have been doing a ton of work with pyuno at work and am interested in anything to improve the code quality there. mike
On Wed, Feb 19, 2014 at 5:02 AM, Stephan Bergmann <sberg...@redhat.com>wrote: > [putting the dev list on CC, quoting the original mail in full below for > reference] > > Hi Kevin, > > First of all: great that you want to improve the PyUNO situation! This is > a part of the code that could indeed benefit from lots of love. > > Regarding the Python tests, I see both sides' points: > > On the one hand, a test in Python indeed does not only serve as a test for > the immediate subject of the test, but also---somewhat indirectly---as a > test of the PyUNO infrastructure and as part of a corpus of PyUNO example > code. This is not much different from how our well-hated so-called > "unoapi" and "complex" tests test URP (and Java) interaction as a side > effect (though they're so ugly that nobody in their right mind would claim > that they are valuable additions to any corpus of example code). > > On the other hand, a test is intended to fail (as soon as you introduce an > error), and should make it easy for the developer to find the underlying > error. For that, any extra layers between the test code and the code under > test are detrimental, in that they make it harder to debug the problem and > introduce the likelihood that a reported error is not actually in the code > under test but rather somewhere else in the infrastructure (which remains > an error that needs to be fixed after all, but less likely by the person > who changed the code under test). > > So, what can we do here? How about an additional code module dedicated to > subsequentchecks written in Python, which, while serving the useful purpose > of testing specific application functionality (and in which role they may > deliberately duplicate existing "native" tests), are meant more as a means > to improve the PyUNO situation. > > The idea would be that Kevin (and others) would fill this with PyUNO > coding scenarios that cross their mind, discover errors in the PyUNO > infrastructure, ideally distill tests for those specific errors out of the > more general tests (that could then even go into more specific code modules > like pyuno or testtools), and eventually prune test snippets again that are > no longer useful. > > What I would like to avoid though is a sort of code dump, filled with > random one-off stuff of little value to anybody. We have < > https://gerrit.libreoffice.org/#/admin/projects/sdk-examples> already, > and it lies virtually dormant. > > How does that sound? > > Stephan > > > On 02/17/2014 08:53 PM, Kevin Hunter Kesling wrote: > >> Hi Stephan, >> >> Markus (moggi) suggested over IRC that I talk to you about how to test >> PyUNO interactions with Calc. The long-winded email below is just >> background for this question: I claim the LibO/Python bindings are weak >> and poorly tested. As my work often presents opportunities that could >> be brilliantly addressed by easier Python scripting of LibO, I'd like to >> improve the Python bindings situation. How best can I accomplish this? >> >> I recently submitted a patch to gerrit that adds a test nominally for a >> recently closed bug: >> >> https://gerrit.libreoffice.org/#/c/8078/ >> >> This test is a functional test of a specific Calc interaction (inserting >> cells). As noted in the commit message, the bug was already quashed, >> and Kohei said in the IRC conversation[1] that the offending library >> (mdds) already has a test for it's role in the related fdo bug. However, >> that still says to me that the actual part that an end-user cares about >> -- in this case the inserting of cells -- is not directly tested. >> >> Through interaction with Kohei and Markus, it's clear that writing the >> tests for the internal workings of a C++ project in Python is not >> acceptable (not the right "tool for the job"), and I can see the >> perspective that not one, but two core maintainers have. >> >> However, this leads me to the larger observation (the one for which I >> originally decided to write the test in Python over C++) is that I see >> hardly any tests of LibO's Python bindings of Calc (sc/). Ideally, I'd >> like to be able to do more Python scripting of LibO, and the quality of >> the bindings is what holds me back. This snippet from the attached >> larger IRC conversation may help elucidate where I'm coming from: >> >> (01:57:35 PM) kohei: and I'm generally not in favor of python >> unit tests. it's not very useful for the maintainers to >> debug failures. >> (01:58:48 PM) frothnicator: kohei: okay, I hear that I don't >> get it. I'm trying to. The only way I know to test and >> learn something is to use it. My main interaction would be >> through UNO, unless I learn of a better way. Thus, when I >> try to introspect an item through Python's REPL, and get >> back an exception for merely calling repr(some_object), or >> my remote connection is broken because of a recoverable >> exception, I don't know what else to call that unstable. >> >> The point being that though I wrote it in Python, the test is actually >> testing multiple things, both of which are important to me: the >> interaction between Python and LibO, and the core functionality that >> motivated the now-abandoned patch. >> >> The more important observation, however, is that while writing this >> test, I encountered many niggles: poor REPL-accessible documentation, >> broken remote connections despite recoverable exceptions, useless >> attempts to introspect object details, undiscoverable imports, other >> crasher bugs, a lack of easily discoverable (read: Googlable) >> Python-based examples from which to learn, and so on. I would not mind >> addressing these as I have time as well. But I need a place to put >> these Python based tests. >> >> The question that was still on my mind after the above interaction was >> "Should I infer that LibO/Python bindings are not a high priority for >> LibO devs?" or "Is using Python with LibO a foolhardy wish on my part?" >> Markus assured me that no one said that, and directed me to ask you. >> >> So, upon articulating my thoughts in this email to you, what I'm really >> looking for is an "in" such that I can help the situation that most >> directly affects me. (The logic being that with luck, I'm not the only >> one who would like to use LibO in this fashion!) I don't expect that >> I'll write perfect code or tests, but that by at least getting the ball >> rolling, iteration -- by me or others -- will fix any issues. (After >> all, that's why we developed revision control systems, yes?!) I, for >> one, would appreciate a more robust Python scripting experience with LibO. >> >> Do you have any suggestions for how I can help improve the PyUNO >> scripter's experience? >> >> Thanks, >> >> Kevin >> >> P.S. I was told to ask you, so I opted to email you directly. If you >> think the -dev list is a more appropriate place for this thread, please >> CC: there as appropriate. >> >> [1] Attached is an IRC conversation from earlier today. >> > > _______________________________________________ > 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
