Create RenderFrame/RenderFrameHost for the main frame of a page.

content/renderer/render_view_browsertest.cc

Index: content/renderer/render_view_browsertest.cc
diff --git a/content/renderer/render_view_browsertest.cc b/content/renderer/render_view_browsertest.cc
index 652b1eab27781952e0a51b9daf569c9904f103e0..b34d21a9f0caa4c35d7b599351a2e27133079e69 100644
--- a/content/renderer/render_view_browsertest.cc
+++ b/content/renderer/render_view_browsertest.cc
@@ -1855,4 +1855,11 @@ TEST_F(RenderViewImplTest, NavigateFrame) {
   EXPECT_EQ(output, L"hello \n\nworld");
 }
 
+// This test ensures that a RenderFrame object is created for the top level
+// frame in the RenderView.
+TEST_F(RenderViewImplTest, BasicRenderFrame) {
+  EXPECT_TRUE(view()->main_render_frame_.get());
+  EXPECT_EQ(view()->routing_id() + 1, view()->main_render_frame_->routing_id());

[jam, 2013/05/31 17:40:04]

this line looks a bit odd. why do we need to test how the routing id's are
assigned?

[nasko, 2013/05/31 17:58:30]

My goal is to test that somehow my code is actually working. Since there is very
little to those classes right now, I thought this is a good way to ensure proper
initialization is done.
In the future, those will likely change, but if people feel strongly about those
checks, I can change them to what Charlie suggested - ensuring one is less than
the other.

[jam, 2013/05/31 18:02:15]

i think a test that checks how the routing ids are generated is not particularly
interesting. it'll pass now, and every time you change the order you'll have to
update it. what kind of regressions are you looking to catch? to give another
example, we never had tests checking the routing ids of RV vs RW or RWH vs RVH,
or these classes vs RP or RPH...

[nasko, 2013/05/31 18:13:38]

I'm fine with that, assuming we don't check other cases either. I removed the
explicit checks for routing ids.

+}
+
 }  // namespace content