Re: SyncML, Google Calendar, and Soup.

[John Stowers <john stowers gmail com>]

On Thu, May 7, 2009 at 11:23 AM, John Carr <john carr unrouted co uk> wrote:

On Wed, May 6, 2009 at 11:51 PM, John Stowers <john stowers gmail com> wrote:
>
>
> 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.

What is this?

http://lwn.net/Articles/333059/

John
 

>> >>
>> >> 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?
>
> John
>

<snip>

I've seen mutterings from:

http://live.gnome.org/DesktopTesting
http://live.gnome.org/DesktopTesting/Documentation/GettingStarted

Its not there yet but i'm hoping there'll be something we can (soft)
depend on and integrate into our make foo and can push to
build.gnome.org.

John