On Fri, Jan 30, 2009 at 9:31 AM, Scott Violet <s...@chromium.org> wrote:
>
> Two new classes to help writing ui tests
>
> I just landed the second part of two chunks that make it easier to
> write and maintain tests that excercise the UI. If you don't write or
> maintain such tests, you can stop reading now.
>
> The first test class is BrowserWithTestWindowTest. This test class
> creates a Browser with a TestingProfile and TestBrowserWindow. Use
> this as a base test class for writing tests that exercise Browser but
> that don't need any sort of UI. For example, many of the commands
> don't need a ui to be tested. See browser_commands_unittest for an
> example of BrowserWithTestWindowTest in action.
>
> BrowserWithTestWindowTest currently works with TestTabContentsFactory
> (a factory that creates a mocked out version of TabContents), which
> does not create HWNDs. I will expand these tests to create a real
> HWND, which will allow for a bit more testing than is currently
> possible.
>
> The second test class is InProcessBrowserTest. This test class invokes
> BrowserMain (but not BrowserInit) to startup Chrome, then runs your
> test method. Your test method is then running as if you were inside
> Chrome. You can create and destroy Browsers, navigate to pages;
> whatever. InProcessBrowserTest can be used as a replacement for
> existing UI tests. See InProcessBrowserTest documentation for details
> as well as find_bar_win_unittest for an example.
>
> Both of these classes work inside the unit_tests project.
>
> This begs the question, do I need to rewrite all my ui tests now? No.
> There is still a need for the automation infrastructure the ui tests
> use (Selenium uses it for one) and as such it won't be going away.
> That said, InProcessBrowserTest is a easier to use than the UI tests
> (you don't need to write IPC messages), should be faster, and is
> easier to debug. For new tests, I strongly encourage you to write them
> using InProcessBrowserTest. Additionally if you find yourself having
> to substantially change around an existing UI test, consider
> converting it over.
There are even more test classes to help you. We also have a new
ability to write more unit tests which are level lower than Scott's
new UI tests. If you derive your unit test class from
RenderViewHostTestHarness
(chrome/browser/renderer_host/test_render_view_host.h), then you will
get a RenderViewHost, RenderWidgetHost, WebContents,
NavigationController, and you should be able to create any of the
services in the profile or the BrowserProcess (maybe with a little
work) and have them live.
Lots of the interstitial ui tests could be written this way, as well
as anything where you want to test the interaction between your
component and something like WebContents (password manager, find in
page, download manager, etc.).
This type of testing uses a stubbed out RenderProcessHost and does not
run a renderer. You can manually send IPC messages from your test, and
also check the MockRenderProcessHost to see what messages we would
have sent to the renderer.
Brett
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
