diff options
author | Allan Sandfeld Jensen <allan.jensen@qt.io> | 2022-09-02 14:22:29 +0200 |
---|---|---|
committer | Allan Sandfeld Jensen <allan.jensen@qt.io> | 2022-09-05 20:21:00 +0000 |
commit | 7d2c5d177e9813077a621df8d18c0deda73099b3 (patch) | |
tree | 88ad4850908e124d4f5d59f2bca571d63df34bf7 /chromium/docs/website/site/Home/domui-testing/index.md | |
parent | c5dbcb143405a38088d78b4b760d64aaff5157ab (diff) | |
download | qtwebengine-chromium-7d2c5d177e9813077a621df8d18c0deda73099b3.tar.gz |
BASELINE: Update Chromium to 102.0.5005.177
Change-Id: I0229f2402b8321f58c0092ec81d63372bec7e789
Reviewed-by: Michael Brüning <michael.bruning@qt.io>
Diffstat (limited to 'chromium/docs/website/site/Home/domui-testing/index.md')
-rw-r--r-- | chromium/docs/website/site/Home/domui-testing/index.md | 127 |
1 files changed, 0 insertions, 127 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 |