Sprinkle some defensiveness into the UI tests so that they don't explode if t...

Sprinkle some defensiveness into the UI tests so that they don't explode if the proxy doesn't respond (e.g., due to a timeout).

BUG=none
TEST=Hopefully the Mac valgrind bots will more reliably run all their tests (although there are likely more issues like this lurking).

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=20096

[Mark Mentovai, 2009-07-07 21:11:12]

LG othewrise

http://codereview.chromium.org/149281/diff/1/8
File chrome/browser/sessions/session_restore_uitest.cc (right):

http://codereview.chromium.org/149281/diff/1/8#newcode205
Line 205: scoped_refptr<TabProxy> tab_proxy(browser_proxy->GetTab(0));
We never use the value initially assigned into tab_proxy.  Do we want to not
give it an initial value, or do we want to ASSERT_TRUE as a check of
browser_proxy->GetTab(0), or do we want to do something with tab 0?

http://codereview.chromium.org/149281/diff/1/9
File chrome/browser/tab_restore_uitest.cc (right):

http://codereview.chromium.org/149281/diff/1/9#newcode260
Line 260: scoped_refptr<TabProxy> tab_proxy(browser_proxy->GetTab(0));
More ASSERT_TRUE here?

http://codereview.chromium.org/149281/diff/1/9#newcode456
Line 456: scoped_refptr<TabProxy> tab(browser_proxy->GetTab(tab_count - 1));
ASSERT_TRUE here too?

http://codereview.chromium.org/149281/diff/1/9#newcode501
Line 501: scoped_refptr<TabProxy> tab(browser_proxy->GetTab(tab_count - 1));
...

http://codereview.chromium.org/149281/diff/1/10
File chrome/browser/views/find_bar_win_uitest.cc (right):

http://codereview.chromium.org/149281/diff/1/10#newcode50
Line 50: ASSERT_TRUE(tabB.get());
Uh-oh, someone didn't compile this!

This should be on the next line.

http://codereview.chromium.org/149281/diff/1/7
File chrome/test/ui/ui_test.cc (right):

http://codereview.chromium.org/149281/diff/1/7#newcode550
Line 550: // Use EXPECT rather than ASSERT here because ASSERT_* returns void.
???

[stuartmorgan, 2009-07-07 21:55:05]

http://codereview.chromium.org/149281/diff/1/8
File chrome/browser/sessions/session_restore_uitest.cc (right):

http://codereview.chromium.org/149281/diff/1/8#newcode205
Line 205: scoped_refptr<TabProxy> tab_proxy(browser_proxy->GetTab(0));
On 2009/07/07 21:11:12, Mark Mentovai wrote:
> We never use the value initially assigned into tab_proxy.  Do we want to not
> give it an initial value, or do we want to ASSERT_TRUE as a check of
> browser_proxy->GetTab(0), or do we want to do something with tab 0?

I have no idea why it's there, and blame doesn't help, so I just remove it and
moved the declaration down to the first real use.

http://codereview.chromium.org/149281/diff/1/9
File chrome/browser/tab_restore_uitest.cc (right):

http://codereview.chromium.org/149281/diff/1/9#newcode260
Line 260: scoped_refptr<TabProxy> tab_proxy(browser_proxy->GetTab(0));
On 2009/07/07 21:11:12, Mark Mentovai wrote:
> More ASSERT_TRUE here?

Done throughout the file.

http://codereview.chromium.org/149281/diff/1/10
File chrome/browser/views/find_bar_win_uitest.cc (right):

http://codereview.chromium.org/149281/diff/1/10#newcode50
Line 50: ASSERT_TRUE(tabB.get());
On 2009/07/07 21:11:12, Mark Mentovai wrote:
> Uh-oh, someone didn't compile this!
> 
> This should be on the next line.

Done.

http://codereview.chromium.org/149281/diff/1/7
File chrome/test/ui/ui_test.cc (right):

http://codereview.chromium.org/149281/diff/1/7#newcode550
Line 550: // Use EXPECT rather than ASSERT here because ASSERT_* returns void.
On 2009/07/07 21:11:12, Mark Mentovai wrote:
> ???

Clarified.

[Mark Mentovai, 2009-07-07 22:31:26]

Looks excellent to me