[Telepathy] tp-ashes meeting review.

[David Laban]

This is a brief overview of the points made when I came to cambs on
Monday to discuss my proposed testing framework.

I have tried to remember who said what. If there's anything I've gotten
the wrong idea about, give me a shout.

David.



Attendees: cassidy, alsuren, wjf, daf



It was noted that Collabora is really an autotools shop, but if I
[alsuren] know how to drive setuptools+nose more reliably then that's
what I should use.

cassidy: For build-bot functinality, it should be possible to specify
configs for test accounts. This should be done by pointing to a dir
containing *.aconf files.

The levels are a good idea, but it should also be possible to add
certain tests to a skip list, or have a "keep going" option so that
tests from all levels can be forced to run if needed.

cassidy: It should also be possible to run single tests on the
command-line [alsuren: you get this functionality for free with nose, I
think]

wjt: it should be possible to run the tests in a random order, in case
some tests only succeed if they are run after others. If calls within a
test can be made in any order, it might be nice to be able to test all
combinations, but not essential [also something about running tests in
parallel, which we agreed would be challenging but not informative.]



The original testing framework is daf's servicetest.py from gabble.
(about 130 tests)

Many tests have been copied directly into haze, but some are
missing/inappropriate.

MC uses servicetest.py too, but really look at gabble for the original.

hyperactivity is a stress-testing framework. It might be worth looking
at this too.


The main wart with servicetest is that it models everything as a single
stream of events. This shouldn't cause me too much of a problem though.

daf: the current testing framework uses a lot of CPU. File transfer
tests also take *ages*. This should be looked into.

Running tests in parallel is *not* the way to speed up tests. While this
may seem like the lay option, the single stream, and use of expect() in
many tests will cause them to fail.




Another thing to look out for is the Telepathy Book, which is currently
missing a section on writing connection managers [if anyone wants to
contribute].


Other business:

Meta-contacts in empathy would be good. There are some [who?] that want
to wait until the planets align and we can do it "right". Planets may
only align once every 7 years though. It was agreed that just dumping
them in an XML file for now, and correcting when the time comes is
probably the best approach. Otherwise we may wait forever.



Integer handles have the following valid rationale:

Provide poor-man's type check.

Provides a normalisation guarantee. (you never want to see
ALSUREN at gmail.com)

Many-one string-int mapping. RequestHandles(InspectHandles(h)) == h. Use
prefixes if you can have the same email address mapping to different
accounts (eg msn/yahoo).

The following arguments are probably not valid:

Speed (let's be honest: dbus is going to be slow whatever happens, and
the only time you *notice* a slowdown is sign-on time, when you will
probably use InspectHandles anyway, since you need to match up chat
history across sessions. Internally, you can use a string table to make
sure you're only ever doing integer compares.

The following problems are found:

A user quickly signing in and out of a chat may have their handle
deleted before it can be inspected. Distributed reference counting is Hard.