In BasicPortAllocator test, don't require a specific candidate order.

In BasicPortAllocator test, don't require a specific candidate order.

The test doesn't really care about the order; the fact that it relied
on a specific order was just an implementation detail.

However, this made the test flaky since race conditions sometimes
determine the order. It also made it frustrating to add new tests.

BUG=webrtc:5930
R=pthatcher@webrtc.org

Committed: https://crrev.com/8c9be5e490903ef00c8acf60cfdc11b80f3c621a
Cr-Commit-Position: refs/heads/master@{#12936}

[Taylor Brandstetter, 2016-05-25 18:51:35]

deadbeef@webrtc.org changed reviewers:
+ pthatcher@webrtc.org

[pthatcher1, 2016-05-25 20:49:05]

https://codereview.webrtc.org/2006263004/diff/20001/webrtc/p2p/client/basicpo...
File webrtc/p2p/client/basicportallocator_unittest.cc (right):

https://codereview.webrtc.org/2006263004/diff/20001/webrtc/p2p/client/basicpo...
webrtc/p2p/client/basicportallocator_unittest.cc:261: return it !=
candidates.end();
Can't this just be the following?

Candidate c;
return FindAndReturnCandidate(candidates,t ype, proto, addr, &c);

?

https://codereview.webrtc.org/2006263004/diff/20001/webrtc/p2p/client/basicpo...
webrtc/p2p/client/basicportallocator_unittest.cc:265: static bool
FindAndReturnCandidate(const std::vector<Candidate>& candidates,
I think it would be more clear if you renamed it a bit:

FindAndReturnX => FindX
FindX => HasX

[Taylor Brandstetter, 2016-05-25 21:48:43]

https://codereview.webrtc.org/2006263004/diff/20001/webrtc/p2p/client/basicpo...
File webrtc/p2p/client/basicportallocator_unittest.cc (right):

https://codereview.webrtc.org/2006263004/diff/20001/webrtc/p2p/client/basicpo...
webrtc/p2p/client/basicportallocator_unittest.cc:261: return it !=
candidates.end();
On 2016/05/25 20:49:05, pthatcher1 wrote:
> Can't this just be the following?
> 
> Candidate c;
> return FindAndReturnCandidate(candidates,t ype, proto, addr, &c);
> 
> ?

Done.

https://codereview.webrtc.org/2006263004/diff/20001/webrtc/p2p/client/basicpo...
webrtc/p2p/client/basicportallocator_unittest.cc:265: static bool
FindAndReturnCandidate(const std::vector<Candidate>& candidates,
On 2016/05/25 20:49:05, pthatcher1 wrote:
> I think it would be more clear if you renamed it a bit:
> 
> FindAndReturnX => FindX
> FindX => HasX

Done.

[pthatcher1, 2016-05-26 17:39:47]

lgtm

[Taylor Brandstetter, 2016-05-26 21:40:03]

The CQ bit was checked by deadbeef@webrtc.org

[commit-bot: I haz the power, 2016-05-26 21:40:13]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2006263004/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2006263004/40001

[commit-bot: I haz the power, 2016-05-26 21:49:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-26 21:49:24]

Try jobs failed on following builders:
  win_x64_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/win_x64_rel/builds/15051)

[Taylor Brandstetter, 2016-05-26 22:24:14]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2016-05-26 22:24:14]

The patchset sent to the CQ was uploaded after l-g-t-m from pthatcher@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2006263004/#ps80001 (title:
" ")

[commit-bot: I haz the power, 2016-05-26 22:24:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2006263004/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2006263004/80001

[Taylor Brandstetter, 2016-05-26 23:07:44]

Description was changed from

==========
In BasicPortAllocator test, don't require a specific candidate order.

The test doesn't really care about the order; the fact that it relied
on a specific order was just an implementation detail.

However, this made the test flaky since race conditions sometimes
determine the order. It also made it frustrating to add new tests.

BUG=webrtc:5930
==========

to

==========
In BasicPortAllocator test, don't require a specific candidate order.

The test doesn't really care about the order; the fact that it relied
on a specific order was just an implementation detail.

However, this made the test flaky since race conditions sometimes
determine the order. It also made it frustrating to add new tests.

BUG=webrtc:5930
R=pthatcher@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/8c9be5e490903ef00c8acf60c...
==========

[Taylor Brandstetter, 2016-05-26 23:07:45]

Committed patchset #5 (id:80001) manually as
8c9be5e490903ef00c8acf60cfdc11b80f3c621a (presubmit successful).

[commit-bot: I haz the power, 2016-05-26 23:07:46]

Description was changed from

==========
In BasicPortAllocator test, don't require a specific candidate order.

The test doesn't really care about the order; the fact that it relied
on a specific order was just an implementation detail.

However, this made the test flaky since race conditions sometimes
determine the order. It also made it frustrating to add new tests.

BUG=webrtc:5930
R=pthatcher@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/8c9be5e490903ef00c8acf60c...
==========

to

==========
In BasicPortAllocator test, don't require a specific candidate order.

The test doesn't really care about the order; the fact that it relied
on a specific order was just an implementation detail.

However, this made the test flaky since race conditions sometimes
determine the order. It also made it frustrating to add new tests.

BUG=webrtc:5930
R=pthatcher@webrtc.org

Committed: https://crrev.com/8c9be5e490903ef00c8acf60cfdc11b80f3c621a
Cr-Commit-Position: refs/heads/master@{#12936}
==========