Re: [Libreoffice] unit-test / code sharing ...

2011-09-29 Thread Michael Meeks
On Wed, 2011-09-28 at 11:47 +0200, Stephan Bergmann wrote: I suspect we should do this for all unit-tests above tools, and the head-less smoketest too. But isn't it the way that all dialogs are implicitly cancelled in headless mode, anyway? Oh - quite possibly for headless

Re: [Libreoffice] unit-test / code sharing ...

2011-09-28 Thread Caolán McNamara
On Wed, 2011-09-28 at 09:46 +0100, Michael Meeks wrote: Reading the various cppunit tests we have and the code cut/paste going on gives some concern. We need a place to share most of this really bootstrap UNO heavy lifting and the various other bits of common magic that go on there, presumably

Re: [Libreoffice] unit-test / code sharing ...

2011-09-28 Thread Stephan Bergmann
On 09/28/2011 11:27 AM, Caolán McNamara wrote: On Wed, 2011-09-28 at 09:46 +0100, Michael Meeks wrote: Reading the various cppunit tests we have and the code cut/paste going on gives some concern. We need a place to share most of this really bootstrap UNO heavy lifting and the various other

Re: [Libreoffice] unit-test / code sharing ...

2011-09-28 Thread Stephan Bergmann
On 09/28/2011 10:46 AM, Michael Meeks wrote: Incidentally, while trying to get some StarBasic / VBA unit tests working with Moggi, it seemed that some of our hangs were down to dialogs showing up that were simply not visible, and spinning the mainloop waiting for a response. static void

Re: [Libreoffice] unit-test / code sharing ...

2011-09-28 Thread Markus Mohrhard
Hello Stephan, 2011/9/28 Stephan Bergmann sberg...@redhat.com On 09/28/2011 10:46 AM, Michael Meeks wrote: Incidentally, while trying to get some StarBasic / VBA unit tests working with Moggi, it seemed that some of our hangs were down to dialogs showing up that were simply not

Re: [Libreoffice] unit-test / code sharing ...

2011-09-28 Thread Caolán McNamara
On Wed, 2011-09-28 at 11:44 +0200, Stephan Bergmann wrote: Yes, test was intended for such stuff -- but we need to make sure not to introduce circular dependencies. (The conceptual level of that module is still somewhat undecided.) fattest/uglytest, slimtest/goodtest if it arises maybe :-)