1071755 - make Loop functional tests work with isolated tokbox mock/fake server

Status: RESOLVED WONTFIX

(Hello (Loop) :: Client, defect)

Description

[Dan Mosedale (:dmosedale, :dmose)]

Loop functional tests currently depend on running against a Loop Server which is configured to go through the live Tokbox network.  Since Tbpl can't afford to have intermittent failures caused by network connectivity issues, we need to do better.

I know the loop-server guys have some kind of stub server that they use for their testing, I suspect it doesn't have the functionality needed for a full call, but I'm hoping I'm wrong about that!  Guys, your thoughts here would be much appreciated it.


Failing that, it's probably worth reaching out to Tokbox to see what they would recommend we do, and if they have any code/infrastructure that they could share with us.

With whatever we use, I suspect we'll want to use the OpenTok "relayed" mode, described in part at <https://tokbox.com/opentok/tutorials/create-session/>.  A previous look at APIs made me suspect that even relayed mode wants to communicate somehow with the OpenTok network, so we'd need to find (or ask for) a way to turn that off.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

It's possible that there is overlap with https://bugzilla.mozilla.org/show_bug.cgi?id=1043266 here.

Comment 2

[Adam Roach [:abr]]

(In reply to Dan Mosedale (:dmose) - not reading bugmail; needinfo? for response from comment #1)
> It's possible that there is overlap with
> https://bugzilla.mozilla.org/show_bug.cgi?id=1043266 here.

It does -- in particular, the long string of adjectives I use in Bug 1043266 comment 12 should give you an idea about the nature of developing a "stub server" as you propose.

Comment 3

[Nils Ohlmeier [:drno]]

This would be nice to achieve.

But I think we actually have two dependencies here:
1) the loop-server uses the TB server SDK to connect to the TB backend
  - it might be doable to fake out that TB backend for testing purposes
2) the loop clients (standalone and conversation/chat-box) use the TB client SDK, which
  a) dynamically loads JS libs from their CDN
  b) connects via WebSocket to the TB signaling servers
  - so in order to fake this out we would need to convince the TB client SDK to connect to our stub signaling server, which then still needs to act like a signaling server, except that it does not need to actually provide TURN servers to the clients (as we assume the clients can connect locally in our tests).

I'm not sure how much work the stub for 2) is, but probably not little. Maybe it makes more sense to ask TB if they have test mock for this already which we could utilize.

Comment 4

[:shell escalante]

Moving these to blocking-loop="tech-debt" so they can be triaged against other tech debt bugs.  When we take a tech-debt bug to work on - just mark it "firefox-backlog"+ and give priority.  Then we'll pull it during iteration planning (or factor it into workload if someone is already working on).

Comment 5

[Ian Bicking (:ianbicking)]

We haven't been seeing many failures due to the TokBox dependency, and this would be hard to do.  So right now it doesn't seem to have enough value to be worth doing.