[Bug 38206] Tp::StreamTubeChannel (and subclasses) don't have unit tests

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=38206

Olli Salli <ollisal at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|telepathy-bugs at lists.freede |andrunko at gmail.com
                   |sktop.org                   |
                 CC|                            |ollisal at gmail.com

--- Comment #1 from Olli Salli <ollisal at gmail.com> 2011-06-17 03:40:18 PDT ---
Andre is working on this stuff. He has a WIP branch at the URL - I'm going to
drop some quick review comments now. He has found some bugs too while testing
the code, and has fixes for those.

> StreamTubeChannel: Make introspectable do not depend on Channel.Type.StreamTube.
> StreamTubeChannel: Fix supportsUnixSocketsWithCredentials.
> TubeChannel: Fix typo in debug message.

++

+    bool initRandom;
This could perhaps be a static variable. The qsrand function sets global state;
we don't need to do that for each tube channel separately.

+bool PendingStreamTubeConnection::requireCredentials() const

This method name is an imperative; and gives the hint that it would actually
make something require credentials. Instead, it's an accessor which checks if
credentials are required. Hence, -> requiresCredentials().

+      g_assert_cmpuint (port, ==,
+          g_value_get_uint (self->priv->access_control_param));

As discussed, you need to fix this spec-incompliant requirement in the test
service (both in our copy and in tp-glib). You can file a separate tp-glib bug
for this, stating that it incorrectly passes only the port where the spec
requires the address and port as a struct, and that's what gabble expects too.
If the tp-glib client side is simple to fix, please do that as well. You don't
need to depend on the tp-glib version with the fixes though, as we have a local
copy of this test service, and the tp-glib copy will be fixed before our next
sync from their test services for sure.

The current test looks broadly OK - unfortunately I don't have time to review
it in detail yet. However, you must also eventually test the connection
monitoring functionality, as it's easily the most complex part of our tube
client code (with the async contact builds). This might or might not require
extensions to the test service.

You should also check, not only for UNIX sockets, but for TCP sockets too, that
the PendingStreamTubeConnection and the tube channel both return a valid
address which one can connect to.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.