summaryrefslogtreecommitdiff
path: root/NEWS
diff options
context:
space:
mode:
authorSimon McVittie <simon.mcvittie@collabora.co.uk>2013-10-02 13:44:10 +0100
committerSimon McVittie <simon.mcvittie@collabora.co.uk>2013-10-02 13:44:10 +0100
commitd0af8d654ae439a1a333c33f6e44084d3dad2afb (patch)
tree6c58a7735c387308f5f62647991f8e615b439510 /NEWS
parentb89f6fe0bcacef9340f633ab09b275122c6db644 (diff)
downloadtelepathy-mission-control-d0af8d654ae439a1a333c33f6e44084d3dad2afb.tar.gz
avatar-refresh test: subsume avatar-persist, and test more situations
We have some sort of combinatorial explosion going on here, and it seems best to test it in a somewhat systematic way: * is the protocol one where avatars persist on the server (Gabble) or not (Salut)? * if it's like Gabble, does it download our own avatar token before signalling CONNECTED (as I suspect Haze does), or on-demand after GetKnownAvatarTokens (as Gabble appears to)? * if it's like Gabble, is the server storing an avatar for us? * in either case, do we have an avatar stored locally, and has it previously been uploaded or not? In addition, the avatar-refresh and avatar-persist tests exercised migration from ~/.missioncontrol and a low-priority XDG_DATA_DIRS entry (respectively) to ~/.local/share. I didn't do that in a loop, because it isn't applicable in all cases and would lead to even more combinations - testing each case once should be enough. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69885 Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk> [cherry-picked from master commit d780671 plus the test part of 4f4ed24, adjusted for old constant naming and to replace unforbid_all() with unforbid_events() -smcv] Conflicts: tests/twisted/account-manager/avatar-persist.py tests/twisted/account-manager/avatar-refresh.py
Diffstat (limited to 'NEWS')
0 files changed, 0 insertions, 0 deletions