diff options
Diffstat (limited to 'chromium/docs/website/site/Home/domui-testing')
3 files changed, 0 insertions, 369 deletions
diff --git a/chromium/docs/website/site/Home/domui-testing/index.md b/chromium/docs/website/site/Home/domui-testing/index.md deleted file mode 100644 index 90a0ae931e8..00000000000 --- a/chromium/docs/website/site/Home/domui-testing/index.md +++ /dev/null @@ -1,127 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -page_name: domui-testing -title: DOMUI Testing ---- - -This document contains a mini design doc for one way to approach testing of -DOMUI pages. - -PLEASE See [WebUI browser_tests](/Home/domui-testing/webui-browser_tests) for -details on current implementation. - -Objective - -Improve quality of DOMUI and find regressions early. - -* Allow unit testing of JS used for DOM UI. -* Allow unit testing of HTML widgets used for DOM UI. -* Allow testing end to end DOMUI - -Problem - -More and more of the UI in Chrome and ChromeOS is built using DOMUI. DOMUI is -the name of Chrome UI built using HTML, JS and CSS with the ability to -comunicate to with the browser process using chrome.send calls. Example of UIs -implemented using DOMUI consists of the New Tab Page, History, Downloads, -Extensions, about:versions and many others. ChromeOS is also in the process of -using DOMUI for menus. - -Testing these UIs is [possible -today](http://www.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/chrome/browser/dom_ui/new_tab_ui_uitest.cc&q=NewTabUITest%20NTPHasLoginName&exact_package=chromium&sa=N&cd=1&ct=rc&l=55) -using -[UITest](http://www.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/chrome/test/ui/ui_test.h&q=%22class%20UITest%22&exact_package=chromium&sa=N&cd=1&ct=rc&l=458) -with DOM automation enabled. However, writing these test require generating -strings of JavaScript code that is (using the automation provider) -asynchronously evaluated in the browser tab and the result of that is -asynchronously returned. - -There are 3 problems with this approach: - -1. Setting up the browser tab requires some C++ and a lot of waiting - for the document to be ready. -2. A string representing the JavaScript needs to be generated. -3. The evaluation is async making test harder to write and more flaky. - -Requirements - -Make it easier to write tests by - -1. Allowing writing the test in JavaScript. After all, we need to use - JavaScript to interact with the UI so it is only natural to do the - test with it. Also dynamic languages are very good for writing unit - tests. -2. Provide a new test class that is specialized for writing tests for - DOMUI. It would wrap up all of the boiler plate code and it - should... -3. Allow any DOM UI to be tested by simply providing the URL of the - page and... -4. Provide the URL or path to the test file and... -5. allow other utility js files to be injected - -It might also be interesting to allow a blank page to be used and just inject -all the js and css we care about. This could be useful for testing widgets in -isolation. - -Solution - -Create a new test class similar to ExtensionBrowserTest but optimized for DOMUI. -This class would have a RunDOMUITest (similar to RunExtensionTest) which would: - -1. Open a tab and navigate to a URL. -2. Inject one or more javascript files. -3. Run tests provided by the JavaScript files (ExtensionBrowerTest uses - a global array of functions to run called test) - -This is better than what we have now for a few reasons: - -* We do not have to open a new browser for every single test. We can - run multiple tests in the same web page. -* We can write the test in JS, reducing the work needed to write - tests. -* We do not have to generate js code and evaluate it using the - automation provider for every single test (these are async) - -Example Use-cases - -The following is based on the same model as the ExtensionApiTest. - -.cc file - -IN_PROC_BROWSER_TEST_F(DOMUITest, NewTabPage) { - -ASSERT_TRUE(RunDOMUITest("chrome://newtabpage", path_to_js_test_file); - -} - -.js file - -var assertEq = chrome.test.assertEq; - -var tests = \[ - -function testLogin() { - -var loginSpan = $(‘login-username’); - -assertEq(loginSpan.textContent, ‘test@gmail.com’); - -} - -\]; - -Tradeoffs - -This solution requires 2 (or more files) for every test. One for the C++ test -function that bootstraps the javascript tests. - -Alternatives - -We could probably do incremental improvements over UITest... - -The most similar thing today is Extension API tests. These are test end to end -of the extension APIs and these use extension pages and - -Another option is to make all DOMUI extensions and just use
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/domui-testing/webui-browser_tests/index.md b/chromium/docs/website/site/Home/domui-testing/webui-browser_tests/index.md deleted file mode 100644 index d63c1a44dc8..00000000000 --- a/chromium/docs/website/site/Home/domui-testing/webui-browser_tests/index.md +++ /dev/null @@ -1,230 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/domui-testing - - DOMUI Testing -page_name: webui-browser_tests -title: WebUI browser_tests ---- - -***Note: This page is out of date. If you are using modern practices, you are -using a BrowserProxy for your JS/C++ interactions. The -[BrowserProxy](https://docs.google.com/document/d/1c20VYdwpUPyBRQeAS0CMr6ahwWnb0s26gByomOwqDjk/edit) -document covers some testing practices for that case.*** - -~~[TOC]~~ - -~~### Problem~~ - -~~See Also [domui-testing](/Home/domui-testing).~~ - -~~WebUI contains Javascript, which runs in the renderer and a C++ handler, which -runs in the UI thread of the browser process. While this is a necessary part of -the design, testing across these boundaries of both language and process/thread -is cumbersome at best.~~ - -~~### Objective~~ - -~~Make it possible to test the Javascript portion of WebUI in Javascript:~~ - -* ~~Write WebUI tests in Javascript.~~ -* ~~Run in browser_tests so that the page is loaded in a real chrome - browser.~~ -* ~~Allow WebUI handlers to be mocked in Javascript.~~ - -~~### Solution~~ - -~~The solution comes in the following parts:~~ - -* ~~Support libraries: `chrome/test/data/webui/test_api.js`, - `chrome/third_party/mock4js/mock4js.js`.~~ -* ~~gyp rules for js2webui generator feeding results into - browser_tests.~~ -* ~~WebUIBrowserTest C++ class in - `chrome/browser/ui/webui/web_ui_browsertest*` .~~ -* ~~Test source files next to the implementation or in - chrome/test/data/webui/ - see - chrome/browser/ui/webui/options/options_browsertest.js and - chrome/test/data/webui/print_preview.js for reference.~~ - -~~### How to write a test~~ - -~~The best reference examples are chrome/test/data/webui/print_preview.js and -chrome/browser/ui/webui/options/options_browsertest.js~~ - -* ~~#### \[maybe\] create a new test file~~ - - * ~~Create new file `chrome/test/data/webui/`*`mytest`*`.js`~~ - * ~~Add `chrome/test/data/webui/`*`mytest`*`.js` to the sources - for browser_tests in `chrome/chrome_tests.gypi`~~ - -* ~~#### Write a test fixture, defining the page to browse to:~~ - -~~```none -/** - * TestFixture for OptionsPage WebUI testing. - * @extends {testing.Test} - * @constructor - **/ -function OptionsWebUITest() {} -OptionsWebUITest.prototype = { - __proto__: testing.Test.prototype, - /** - * Browse to the options page & call our preLoad(). - **/ - browsePreload: 'chrome://settings-frame', - // ... -}; -```~~ - -* ~~#### Mock the Javascript handler:~~ - -~~```none -OptionsWebUITest.prototype = { -... - /** - * Register a mock handler to ensure expectations are met and options pages - * behave correctly. - **/ - preLoad: function() { - this.makeAndRegisterMockHandler( - ['defaultZoomFactorAction', - 'fetchPrefs', - 'observePrefs', - 'setBooleanPref', - 'setIntegerPref', - 'setDoublePref', - 'setStringPref', - 'setObjectPref', - 'clearPref', - 'coreOptionsUserMetricsAction', - ]); - // Register stubs for methods expected to be called before/during tests. - // Specific expectations can be made in the tests themselves. - this.mockHandler.stubs().fetchPrefs(ANYTHING); - this.mockHandler.stubs().observePrefs(ANYTHING); - this.mockHandler.stubs().coreOptionsUserMetricsAction(ANYTHING); - }, -... -}; -```~~ - -* ~~#### Mock stubs which call a function:~~ - -~~```none - mockHandler.stubs().getDefaultPrinter(). - will(callFunction(function() { - setDefaultPrinter('FooDevice'); - })); -```~~ - -* ~~#### Define a test using mock expectations:~~ - -~~```none -TEST_F('OptionsWebUITest', 'testSetBooleanPrefTriggers', function() { - var showHomeButton = $('toolbarShowHomeButton'); - var trueListValue = [ - 'browser.show_home_button', - true, - 'Options_Homepage_HomeButton', - ]; - // Note: this expectation is checked in testing::Test::TearDown. - this.mockHandler.expects(once()).setBooleanPref(trueListValue); - // Cause the handler to be called. - showHomeButton.click(); - showHomeButton.blur(); -}); -```~~ - -* ~~#### Conditionally run a test using generated c++ ifdefs:~~ - -~~#### See [Handling a failing test](/developers/tree-sheriffs/handling-a-failing-test) for more details on style and how/when to disable a test.~~ - -~~```none -// Not meant to run on ChromeOS at this time. -// Not finishing in windows. http://crbug.com/81723 -GEN('#if defined(OS_CHROMEOS) || defined(OS_MACOSX) || defined(OS_WIN) \\'); -GEN(' || defined(TOUCH_UI)'); -GEN('#define MAYBE_testRefreshStaysOnCurrentPage \\'); -GEN(' DISABLED_testRefreshStaysOnCurrentPage'); -GEN('#else'); -GEN('#define MAYBE_testRefreshStaysOnCurrentPage ' + - 'testRefreshStaysOnCurrentPage'); -GEN('#endif'); -TEST_F('OptionsWebUITest', 'MAYBE_testRefreshStaysOnCurrentPage', function() { - var item = $('advancedPageNav'); - item.onclick(); - window.location.reload(); - var pageInstance = AdvancedOptions.getInstance(); - var topPage = OptionsPage.getTopmostVisiblePage(); - var expectedTitle = pageInstance.title; - var actualTitle = document.title; - expectEquals("chrome://settings/advanced", document.location.href); - expectEquals(expectedTitle, actualTitle); - expectEquals(pageInstance, topPage); -}); -```~~ - -~~### Maintaining~~ - -* ~~Adding more goodies to generator - edit - `chrome/test/ui/webui/javascript2webui.js` and tests in - `chrome/test/data/webui/`.~~ -* ~~Disabling a test - find tests in `chrome/test/data/webui/` & mark - `FLAKY_`, `DISABLED_` or use the `MAYBE_` trick shown above to - conditionally decide.~~ - -~~### Considerations/FAQs~~ - -* ~~*Isn't mocking in javascript not testing the WebUI message - passing?* True, but that should be tested as a unit test and then - trusted. Mocking in JS is easier, less flaky (always recursive - no - synchronization challenges) and much better than not having any - tests at all.~~ -* ~~*If you already have the page in question why don't you just run - all tests without starting a new IN_PROCESS_BROWSER_TEST?* You are - more than welcome to group tons of expect\* calls into a single - test; all errors will be reported after the entire test runs. Having - tests be separate IN_PROCESS_BROWSER_TEST calls ensures the state is - exactly the same at the start of each tests with no pollution from - previous tests.~~ - -~~### Caveats~~ - -* ~~\[[crbug.com/88104](http://crbug.com/88104)\] The generator relies - on d8 to be built for the host. Currently the v8.gyp rules aren't - correct for Arm as they have conditionals on the 'target_host' and - don't heed the 'toolset". A gyp condition only runs the js2webui - rule on non-arm platforms.~~ -* ~~Use of `MAYBE_` to ifdef will have a different run name from GTEST - than from `test_api.js` - this is because `MAYBE_xyz` will be - defined as either `xyz` or `DISABLED_xyz` in C++, but not changed in - javascript.~~ - -~~### Best practices~~ - -* ~~As described in the [gtest - docs](http://code.google.com/p/googletest/), prefer expect\* over - assert\*, as it will not halt the test, but will register the - failure and allow other checks in that particular testcase to run.~~ -* ~~Since the call is included in the failure error message, the - optional `message` parameter should only include information not - available:~~ - -~~```none -// NO -TEST_F('FooTest', 'TestFoo', function() { - expectEquals(foo, bar, 'foo != bar'); - expectEquals(foo, bar, foo + '!=' + bar); - var i = ...; - expectEquals(5, array[i], 'array[i] != 5'); -}); -// YES -TEST_F('FooTest', 'TestFoo', function() { - expectEquals(foo, bar); - expectEquals(foo, bar); - var i = ...; - expectEquals(5, array[i], 'i=' + i); -}); -```~~
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/domui-testing/webui-browser_tests/webui-accessibility-audit/index.md b/chromium/docs/website/site/Home/domui-testing/webui-browser_tests/webui-accessibility-audit/index.md deleted file mode 100644 index 8b3d656578a..00000000000 --- a/chromium/docs/website/site/Home/domui-testing/webui-browser_tests/webui-accessibility-audit/index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/domui-testing - - DOMUI Testing -- - /Home/domui-testing/webui-browser_tests - - WebUI browser_tests -page_name: webui-accessibility-audit -title: WebUI accessibility audit ---- - |