Mocking OpenOffice in python?
fred at adventistcare.org
Wed Mar 14 15:49:42 CET 2007
I currently use Java to generate a 150 page PDF from about 50 .odt files,
including replacing occurrances of about 10 "place-holder" phrases from data
in our system. I do not use the OOo database/mailmerge features, just UNO.
This process takes about 20 seconds on my 2 year old XP laptop and about 10
seconds on our Linux doc server.
So the key problem may be your approach to generating the OO being to slow,
rather than needing a way to speed up testing.
I use a std java property file/url to define the search/replace pairs and to
contol insert of the conditional documents.
FWIW the internal .odt is XML once it is unzipped.
From: python-list-bounces+frsells=adventistcare.org at python.org
[mailto:python-list-bounces+frsells=adventistcare.org at python.org]On
Behalf Of PaoloB
Sent: Wednesday, March 14, 2007 9:11 AM
To: python-list at python.org
Subject: Re: Mocking OpenOffice in python?
On 14 Mar, 14:48, Carsten Haese <cars... at uniqsys.com> wrote:
> On Wed, 2007-03-14 at 01:39 -0700, PaoloB wrote:
> > Hi everyone,
> > during our development, we need to write some unit tests that interact
> > with OpenOffice through pyUno.
> > Is there anyone who has got any experience on it? As OpenOffice is
> > quite a large beast, and interaction is rather complex, I would like
> > to know if there is someone who is willing to share experience (and,
> > possibly, code).
> I have some experience with pyuno, but your question is very open-ended.
> It would be helpful if you asked specific questions or gave more
> background on what kind of interaction you're trying to achieve.
> The generic answer to your request for code examples is that there's a
> tutorial with example code
athttp://udk.openoffice.org/python/python-bridge.html, and then there's
> the API documentation
basically, our project (PAFlow) is an application for producing
documents in public administrations.
We create templates using OpenOffice, that are filled automatically
using data from the application itself.
Now, interacting with OpenOffice is slow, and our tests get a lot of
time to be executed automatically.
We are trying to mock OpenOffice, so that we can run our tests without
using a true OpenOffice for our tests, except when we express test the
filling of data and production of document.
More information about the Python-list