Enable SequencedSocketDataTest.SingleSyncWriteTooSmall test.

Enable SequencedSocketDataTest.SingleSyncWriteTooSmall test.

SequencedSocketDataTest.SingleSyncWriteTooSmall confirms that errors will be generated when the SequencedSocketData provider is set up with too large write expectations.

The test was previously disabled because it used EXPECT_NONFATAL_FAILURE to do the confirmation. EXPECT_NONFATAL_FAILURE can only handle one failure, and this error case generates three.

There is not a comparable macro for multiple failures in the gtest framework, but tests can directly access the failures using the TestPartResultArray data structure and the ScopedFakeTestPartResultReporter to capture the failures.

BUG=488072
Committed: https://crrev.com/2115662212f026c1710870dcc53906bea9e38814
Cr-Commit-Position: refs/heads/master@{#332420}

[cbentzel, 2015-06-01 19:52:12]

cbentzel@chromium.org changed reviewers:
+ rch@chromium.org

[cbentzel, 2015-06-01 19:52:12]

Hey Ryan - tell me what you think of this approach.

I considered writing a class such as MultipleTestFailureExpector where you could
add test failure messages, and it would accumulate all test failures and
validate them in the destructor.

If I needed to replicate the logic I added to this test in another place, I'd
certainly do it - but it felt like a bit of overkill for just one location.

---

My other concern is whether this goes a bit too much into the guts of gtest. All
of the classes it uses are marked with GTEST_API_ macros, and are not part of
the ::testing::internal namespace, but I'm still concerned that this may be a
bit fragile.

[Ryan Hamilton, 2015-06-02 15:56:27]

LGTM

On 2015/06/01 19:52:12, cbentzel wrote:
> Hey Ryan - tell me what you think of this approach.
> 
> I considered writing a class such as MultipleTestFailureExpector where you
could
> add test failure messages, and it would accumulate all test failures and
> validate them in the destructor.
> 
> If I needed to replicate the logic I added to this test in another place, I'd
> certainly do it - but it felt like a bit of overkill for just one location.
> 
> ---
> 
> My other concern is whether this goes a bit too much into the guts of gtest.
All
> of the classes it uses are marked with GTEST_API_ macros, and are not part of
> the ::testing::internal namespace, but I'm still concerned that this may be a
> bit fragile.

yeah, it's a but heavy on gtest but at the end of the day, I think it's a good
tradeoff.

[cbentzel, 2015-06-02 17:16:50]

The CQ bit was checked by cbentzel@chromium.org

[commit-bot: I haz the power, 2015-06-02 17:19:47]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1158573004/1

[commit-bot: I haz the power, 2015-06-02 17:28:09]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-06-02 17:29:02]

Patchset 1 (id:??) landed as
https://crrev.com/2115662212f026c1710870dcc53906bea9e38814
Cr-Commit-Position: refs/heads/master@{#332420}