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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Jun 27 21:56:54 CEST 2011


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

--- Comment #2 from Andre Moreira Magalhaes <andrunko at gmail.com> 2011-06-27 12:56:53 PDT ---
(In reply to comment #1)
> +    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.
Done

> +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().
Done

> +      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.
Done, tp-glib patches will come later when I finish this.

> 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.
In progress.

The updated branch now also enables tests for Port access control.

The downside is that I was unable to test Tcp+Port using Qt sockets directly. I
used G*Socket* instead, see the test for more details.

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



More information about the telepathy-bugs mailing list