Re: SyncML, Google Calendar, and Soup.

[John Carr <john carr unrouted co uk>]

New to me :)

On Thu, May 14, 2009 at 1:43 AM, John Stowers <john stowers gmail com> wrote:
>
>
> 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
>
>