components_unittests: content::RenderFrameHosts for subframes?

11 views
Skip to first unread message

Václav Brožek

unread,
Dec 23, 2016, 11:39:24 AM12/23/16
to chromi...@chromium.org
Hi all,

I am trying to write a unit test for ContentAutofillDriverFactory. The factory is associated with a WebContents, and for every RenderFrameHost (RFH) created in that WebContents, the factory creates a ContentAutofillDriver. The factory keeps all the drivers keyed by the corresponding RFH instances. In Chrome, the RFH is also directly used by the driver, but not in my test. In the test the RFH pointers only serve to be the key in the factory's map, an identifier for the associated ContentAutofillDriver.

When using content::RenderViewHostTestHarness, I get a WebContents with a single created RFH (GetMainFrame()).

Question: How do I create more RFH instances simultaneously for the same WebContents (to simulate subframes)?

While //content/test might have some tools, ContentAutofillDriverFactory sits in //components/autofill/content/browser/. If I put the unit test to the same, then only //content/public/* is available to it. I would also like to avoid doing a browser test instead, seems like an overkill for what I want to test.

There seems to be no easily constructible implementation of RFH offered in //content/public/*. Creating my own mock also does not work: RFH only has a private constructor, with a note: "This interface should only be implemented inside content."

Because I only use the RFH as a key in a map, I could just reinterpret_cast some non-zero values and pass them to ContentAutofillDriverFactory::RenderFrameCreated.

So I have 3 potential ways to solve this:
  • the above reinterpret_cast hack,
  • writing a browser test instead,
  • moving the test somewhere to //content (not sure if that would help).
Out of those, I prefer the reinterpret_cast, but I'm curious whether anybody has another suggestion?

Thanks!
Vaclav

Václav Brožek

unread,
Dec 23, 2016, 11:52:46 AM12/23/16
to chromi...@chromium.org
On Fri, 23 Dec 2016 at 17:37 Václav Brožek <va...@chromium.org> wrote:
Hi all,

I am trying to write a unit test for ContentAutofillDriverFactory. The factory is associated with a WebContents, and for every RenderFrameHost (RFH) created in that WebContents, the factory creates a ContentAutofillDriver. The factory keeps all the drivers keyed by the corresponding RFH instances. In Chrome, the RFH is also directly used by the driver, but not in my test. In the test the RFH pointers only serve to be the key in the factory's map, an identifier for the associated ContentAutofillDriver.

When using content::RenderViewHostTestHarness, I get a WebContents with a single created RFH (GetMainFrame()).

Question: How do I create more RFH instances simultaneously for the same WebContents (to simulate subframes)?

While //content/test might have some tools, ContentAutofillDriverFactory sits in //components/autofill/content/browser/. If I put the unit test to the same, then only //content/public/* is available to it. I would also like to avoid doing a browser test instead, seems like an overkill for what I want to test.

There seems to be no easily constructible implementation of RFH offered in //content/public/*. Creating my own mock also does not work: RFH only has a private constructor, with a note: "This interface should only be implemented inside content."

Because I only use the RFH as a key in a map, I could just reinterpret_cast some non-zero values and pass them to ContentAutofillDriverFactory::RenderFrameCreated.

Turns out this won't work either, one of a cascade of classes created during a ContentAutofilLDriver creation uses the RFH. Even if it worked now, this would certainly break in the future.

Instead, I'm going to modify the factory to accept a method to create the ContentAutofillDriver, and inject one for creating mocked drivers in the test. That way the only production class created will be the factory itself, which seems ideal for unit testing.

Still, I'm happy to hear any suggestions to the topic of creating RFHs in tests, for future reference.

Cheers,
Vaclav
Reply all
Reply to author
Forward
0 new messages