[asterisk-dev] [Code Review] 3361: rest_api/bridges/subscription: Update test to accomodate r410528
Jonathan Rose
reviewboard at asterisk.org
Fri Mar 21 14:14:01 CDT 2014
> On March 21, 2014, 2:13 p.m., Jonathan Rose wrote:
> > Ship It!
Following kmoore's suggestions that is.
- Jonathan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3361/#review11318
-----------------------------------------------------------
On March 14, 2014, 4:23 p.m., Matt Jordan wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3361/
> -----------------------------------------------------------
>
> (Updated March 14, 2014, 4:23 p.m.)
>
>
> Review request for Asterisk Developers, David Lee, Joshua Colp, and kmoore.
>
>
> Repository: testsuite
>
>
> Description
> -------
>
> The change in r410528 (https://reviewboard.asterisk.org/r/3336/) introduced a subtle behaviour change that broke the rest_api/bridges/subscription test. Previously, the test did the following:
>
> * Create a Stasis application 'testsuite'
> * Create a Stasis application 'bridge-watching-app'
> * POST a channel to application 'testsuite'
> * POST a bridge
> * Subscribe application 'bridge-watching-app' to the bridge
> * Add the previously posted channel to the bridge
> ** Verify that the app 'testsuite' sees the bridge update (as its channel is in the bridge)
> ** Verify that the app 'bridge-watching-app' sees the bridge update (as it was subscribed)
> * Unsubscribe the app 'testsuite' from the bridge
> * Remove the channel from the bridge
> ** Verify that the app 'bridge-watching-app' see the bridge update
> ** Verify that the app 'testsuite' does NOT see the bridge update <------------ THIS IS NOW BROKEN
>
> The last verification broke because we now ensure that applications who have channels in a bridge are now subscribed implicitly to the bridge while their channel is in it. You can now no longer unsubscribe from the implicit subscription created by your channel: you may decrement the subscription count, but it won't be sufficient to nuke out the subscription that ARI has created for you.
>
> I actually think this behaviour change is a good thing: If you have a channel in an application, and it is doing "things", you should always be notified of the "things" it is doing. Even if you claim you don't want to know - otherwise, how do you know when you can DELETE the channel? Or do something else crazy to it?
>
> This test has now been updated so that the thing unsubscribed is the 'bridge-watching-app'. This still verifies subscribes/unsubscribes - but it does so where the entity subscribing for the bridge updates never had a 'stake' in the state of the bridge in the first place.
>
>
> Diffs
> -----
>
> /asterisk/trunk/tests/rest_api/applications/subscribe-bridge/test-config.yaml 4844
> /asterisk/trunk/tests/rest_api/applications/subscribe-bridge/subscribe_bridge.py 4844
>
> Diff: https://reviewboard.asterisk.org/r/3361/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Matt Jordan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140321/20710d0e/attachment.html>
More information about the asterisk-dev
mailing list