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 [email protected]) 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. _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
