Conversation
tests/system/nvdaSettingsFiles/standard-dontShowWelcomeDialog.ini
Outdated
Show resolved
Hide resolved
See test results for failed build of commit 6d05096a6c |
See test results for failed build of commit f30e7bd108 |
|
The last CI run had test failures: I7562From RF log. Last check while waiting for Chrome (total 3 seconds of waiting): From NVDA log NVDA report Chrome opening the tab: ARIA checkboxFrom RF log. Trying to read title (NVDA+t), speech didn't finish within 5 seconds From NVDA log, error with gesture NVDA+t. Second time it has been run. This seems strange. Starts from desktop shortcutRF log: Note NVDA is already running, and is providing the connection to RF. NVDA log: This indicates it was about 5 seconds from NVDA shutdown until the RF remote error. Test SelByWordFailed because there were multiple notepad windows open with the same title: It's unknown why one of the notepad windows didn't close at the end of test, the screenshot doesn't give any indication, the "old" notepad instance is obscured by the new one. Several tests use this same sample/title, from test "Test MoveByWord" This is the only instance of "leaving process intact" in the log. |
See test results for failed build of commit a399f46ae7 |
See test results for failed build of commit 1892cd58a9 |
See test results for failed build of commit 0e1983ccbf |
… environment var (PR #14055) Related to PR #14054 Summary : When tests are failing in an unusual way, it may be helpful to be able to review verbose debug logging for interaction with MSAA or UIA. For developers: VERBOSE_SYSTEM_TEST_LOGGING can be set (to "true") via Appveyor settings to enable high verbosity NVDA logging. Development approach: When the environment variable VERBOSE_SYSTEM_TEST_LOGGING is set on appveyor, the system tests are started with an extra parameter (verboseDebugLogging='True') which enables the advanced logging categories in NVDA.
Since Appveyor seems to be less performant than previously, give NVDA more time to handle events and get all speech out. This will increase the time system tests take. System tests could be optimised to reduce usages of wait_for_speech_to_finish. In many cases, wait_for_specific_speech could be preferable.
Seeing focus / nav / browsemode during tests can help some developers with debugging issues with the tests.
Some config can affect the way the test samples are prepared, E.G. moving focus / review to the start location.
Prior approach was flowed, the 'start.exe' process was being tracked instead. The 'start.exe' process exited immediatly after starting notepad. Now it waits until the process is complete. Additionally the notepad RF lib has access to the Windows HWND allowing for checking if the window is in the foreground.
04531a5 to
34361ba
Compare
|
This work has been split up, and entirely delivered via other PRs. Closing. |
Splitting up PR #14054 Summary of the issue: When a system test fails a screenshot is captured. However, this does not make it clear where the focus/ nav / virtual cursor is positioned. Description of user facing changes None Description of development approach Seeing focus / nav / virtual cursor during tests can help some developers with debugging issues with the tests.

Link to issue number:
Related to #13983
Follow on from #14004
Summary of the issue:
System tests continue to fail intermittently.
This docker desktop window opened in the foreground (meaning Appveyor build window no longer is in the foreground) and caused system tests that rely on a 3rd party window taking the foreground to fail.
Description of user facing changes
For developers, the system tests shouldn't fail intermittently.
Description of development approach
Testing strategy:
Known issues with pull request:
None
Change log entries:
None
Code Review Checklist: