Re: SyncML, Google Calendar, and Soup.

On Thu, May 7, 2009 at 9:19 AM, John Carr <john carr unrouted co uk> wrote:
On Wed, May 6, 2009 at 9:17 PM, John Stowers <john stowers gmail com> wrote:
> On Thu, May 7, 2009 at 1:46 AM, John Carr <john carr unrouted co uk> wrote:
>> Quick update,
>> SyncML support has continued to mature. I'm reasonably happy with how
>> trunk libsyncml and this branch are performing against ScheduleWorld.
>> Going to check it still works with my phone shortly.
>> I think initial syncml support will be ready to merge soon.
>> Spent some time on my AutoSoup replacement. So far i've written 6
>> tests to test the interface of a DataProvider, 5 to test basic
>> DataType behavior and 11 simple sync scenario tests (things like 'what
>> happens if i add stuff, sync, modify stuff, sync). At the moment a
>> 'full run' runs 202 combinations of these tests (in less than 30
>> seconds) (this is covering the folder, ipod and n800 backends, with
>> tomboy and evolution both pending). There are currently 10 failures,
>> which represent 2 bugs. One of which is some of the iPod backends dont
>> support put overwrites, they just add new data :( :(
> Sounds fantastic!
>> It also gained code coverage and profiling support. Should also gain
>> some crack to run tests with their own session dus and grab
>> dbus-monitor logs of the test run (its about half way there). I'm also
>> going to add options to drop you into pdb on exceptions and to run a
>> test in the debugger.
> Gained code coverage? We already have code coverage... Gained relative to
> what?

Sorry, glossed over the details.

At first i was going to try and fix up the Auto* foo in place, but it
was a bit tricky to do everything i wanted. I ended up working on it
in parallel (tests/soup vs tests/python-tests). While it meant i didnt
have to worry about breaking the existing stuff while i did what i
wanted it did mean i experimented a bit more. This included a python
test runner. Added coverage to it to see if it was possible to get it
to the point where it could replace run-scripts (or mostly replace
it). I've now refactored that so that we can tweak the envrionment a
test runs in without too much spaghetti code - implement an interface
and you get callbacks at appropriate times. As well as coverage, then
added code to instrument each test with a cProfile.runcall( )
decorator, to start a new session bus for the tests and to produce
dbus-monitor logs for each test. Obviously not all at once :)

Ahh excellent. That makes sense now

>> I'm also trying not to stray too far from unittest style tests, so it
>> should be possible to have an optional dependency on python-testtools
>> in the future and allow multiple tests to run at the same time.
>> I'd like some feedback on this sooner rather than later (before i
>> start testing syncml with it).
> I will take a closer look at this over the weekend, I have a paper due, but
> I would just like to raise one thing while I remember.
> I would like to be able to in future, test elements of the GUI. Which I
> presume means starting up and Xnest instance, and running LDPT, dogtail, or
> other ATK based gui testing tools. I would hope the the *test setup* step,
> for example that runs Conduit with its own private session bus, would be
> extendable to do this, and tear down Xnest after the test.
> I would also like to use said infrastructure in future, to take screenshots,
> and test all the dataprovider configuration widgets.

I think its extendible enough. But i'm hoping the infrastructure
upstream will be good enough to do all setup that for us.

Infrastructure upstream? Are you implying that GNOME will be hosting some sort of testing framework thing, or do you mean upstream = us?


> Regards
> John
>> John
>> On Mon, Apr 27, 2009 at 2:31 PM, John Carr <john carr unrouted co uk>
>> wrote:
>> > Hi Guys,
>> >
>> > Just an update on my SyncML efforts (and other work). You can check
>> > out the progress on github:
>> >
>> >
>> >
>> > Currently the work has concentrated on acting as a HTTP client (for
>> > synchronising to Schedule World) and Bluetooth OBEX (for synchronising
>> > to mobile phones). libsyncml doesn't have any python bindings upstream
>> > so i bound the new "easy" data sync api found in recent versions (i'm
>> > testing with libsyncml 0.5.2). It's a ctypes binding thats mostly
>> > generated automatically using some Vala crack i wrote - so want to
>> > avoid editing it directly.
>> >
>> > Most of the work is in the SyncmlDataProvider class. This handles the
>> > delicate dance between Conduit threading and libsyncml threading. This
>> > still needs work to handle error cases better (read: at all). It
>> > handles both the Server and Client SyncML modes (if you are unfamiliar
>> > with SyncML: A server can initiate a connection to a client just as a
>> > client can initiate a connection). A server can also request slow or
>> > fast syncs, so if a remote is only sending changes we implement
>> > get_changes(), otherwise we raise NotImplementedError and fallback to
>> > get_all(). Note to self: Need to sit down with a pen and paper and
>> > think what it means if we only send changes during a slow sync.
>> >
>> > There are mixins to specialise this provider to deal in Events and
>> > Contacts and mixins to configure for typical HTTP client access and
>> > typical Bluetooth OBEX. Theres also a simple BluetoothFactory that
>> > creates DataProviders for paired bluetooth devices (and removes them
>> > if the device is unpaired).
>> >
>> > Not ready to merge just yet, but getting there. Concentrating on
>> > ScheduleWorld right now which works one way but is having trouble in
>> > two way.
>> >
>> > Also on my github you will find:
>> >
>> > A branch to turn Google Calendar back on. Not much to say on this. I
>> > havent had time to stress test Google Calendar yet but i'm hoping to
>> > find time. A lot of people keep asking where this went - i'd like to
>> > merge and turn it back on if possible.
>> >
>> > A branch for a new approach to my old (presumed bitrotted) AutoSoup
>> > tests. You create a class for each dataprovider that knows how to set
>> > up a test instance and optionally how to validate test outcomes (there
>> > is a default implementation this is the case for the syncml provider).
>> > A stock interface test and sync test is then generated for each
>> > dataprovider. In the case of the sync test, it generates a test for
>> > each combination of dataprovider (thats makes sense). The aim here is
>> > to be able to give each dataprovider a brutal testing whilst needing
>> > hardly any custom code. Nowhere near ready to merge, but wouldnt mind
>> > input (especially objections) before i waste too much time.
>> >
>> > John
>> >
>> _______________________________________________
>> Conduit-list mailing list
>> Conduit-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]