784f5d76b9
Previously, only the first B?XFAIL would be reported, all others would be discarded. Furthermore, if a B?XFAIL had happened, B?PASS was also not reported, since the B?XFAIL served as test line. However, if the B?XFAIL was followed by a SKIP, B?XPASS or B?FAIL, these were reported as normal, producing exactly the kind of duplicated test line that the skipping of B?PASS was meant to supply. So change B?XFAIL to be reported among the messages, but retain the TODO annotation of the first on the test line of a subsequent B?PASS, if nothing more drastic happens in the mean time. So now more than one B?XFAIL can be reported, the test is still marked as a TODO and we don't get duplicate test lines for a subsequent non-passing result. This replaces the bool m_wasExpectedFail member with a QTestCharBuffer m_firstExpectedFail that records the first XFAIL's TODO line (so its isEmpty() fully replaces m_wasExpectedFail). Previously, the at/file/line information for a B?XFail would be supplied as top-level keys in the YAML block for a "Pass" reported as not ok due to the XFail, as this location information is now part of the B?XFail's message in the extensions/messages block. Duplicating the first B?XFail's location at top level would add complexity and is arguably misleading, as the test result is really a pass (after ignoring known issues), and the location of the pass is indeterminate (nominally the end of the test function, but actually also after the cleanup() call for this test, when relevant), which is why a Pass has no location information. Task-number: QTBUG-96844 Change-Id: Ib3f24f56266ff49bf3bc9759ac8263ac69a62130 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> |
||
|---|---|---|
| .. | ||
| auto | ||
| baseline | ||
| benchmarks | ||
| global | ||
| libfuzzer | ||
| manual | ||
| shared | ||
| testserver | ||
| CMakeLists.txt | ||
| README | ||
This directory contains autotests and benchmarks based on Qt Test. In order
to run the autotests reliably, you need to configure a desktop to match the
test environment that these tests are written for.
Linux X11:
* The user must be logged in to an active desktop; you can't run the
autotests without a valid DISPLAY that allows X11 connections.
* The tests are run against a KDE3 or KDE4 desktop.
* Window manager uses "click to focus", and not "focus follows mouse". Many
tests move the mouse cursor around and expect this to not affect focus
and activation.
* Disable "click to activate", i.e., when a window is opened, the window
manager should automatically activate it (give it input focus) and not
wait for the user to click the window.