On Wed, May 6, 2009 at 9:17 PM, John Stowers <john stowers gmail com> wrote:Sorry, glossed over the details.
>
>
> 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?
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 :)
I think its extendible enough. But i'm hoping the infrastructure
>> 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.
upstream will be good enough to do all setup that for 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:
>> >
>> > http://github.com/Jc2k/conduit/tree/syncml
>> >
>> > 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
>> http://mail.gnome.org/mailman/listinfo/conduit-list
>
>