Selftests for testlib fail when executed in UTC timezone because local and
UTC are the same, but expected to be different. A custom timezone is used
instead.
Debug output of qCompare does only handle local and non-local timezones, using
new Qt5 features allows to show the correct timezone in format string.
Change-Id: I753884a12370952b7b62a90d62896db4f2d3d1b4
Reviewed-by: Jason McDonald <macadder1@gmail.com>
[ChangeLog][QtTest] Added test duration to xml output.
When running tests with xml output a new tag of the form
<duration msecs="123"/> is added to each test function and the test as a
whole.
Change-Id: Ibc4db066b6acf5fac6c578f5e5ca5ce4b5d8ea8e
Reviewed-by: Sergio Ahumada <sahumada@blackberry.com>
Reviewed-by: Jason McDonald <macadder1@gmail.com>
The newly added generate_expected_output.py was used to get the expected
output into a more reproducible state.
Change-Id: I1ca75c8e0c5778d25c1df531bd298007aac0ff4a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Before:
FAIL! tst_testcase::testcase: Compared values are not the same
Actual (actual): F0O
Expected (expected): FOO
Now:
FAIL! tst_testcase::testcase: Compared values are not the same
Actual (actual) : F0O
Expected (expected): FOO
Change-Id: I6f0768e4ef53e065b85a56879cecbad06fa34aef
Reviewed-by: Jason McDonald <macadder1@gmail.com>
If an URL is invalid, let's indicate that in the test output. To be
helpful, let's make QUrl::errorString() include the component form of
the URL.
Change-Id: Iaafe16973ded79c7ea688fbb23808d91253e8c14
Reviewed-by: David Faure <faure@kde.org>
Future-proofing. Since Qt source code is now mandated to be in UTF-8,
it is entirely possible that someone will use non-ASCII in data tags.
Though it would be interesting to see how to access them from the
Windows command-line.
Change-Id: I880fc312432b62143888ff1e1d9abbd54f704601
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
Make the various versions of the failure message align consistently so
that it's a little easier to compare the actual and expected values. Of
course, the value won't align nicely unless the "actual" and "expected"
strings are the same length, but at least this commit makes that
consistent across all versions of the message.
Change-Id: If9ce231df3b5d279a06f6458fdb5da0aa4586068
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
For data-driven tests, testlib previously counted one fail or skip for
each data row that failed or skipped, while it counted only one pass
for a test function where all rows passed and counted no passes for a
test function where some rows passed and some rows failed. A similar
problem also existed for benchmark tests, which could run multiple
iterations of the same test, with each fail and skip being counted but
only a single pass being counted for the entire series of iterations.
This commit makes testlib count one pass, fail or skip for each data
row. Test functions that are not data-driven count one result for the
test function, as before. Benchmark tests count one pass, fail or skip
per iteration.
A side-effect of this change is that the test output in plain text, xml
and light xml formats now shows a result for every data row and
benchmark iteration executed, allowing post-processors to correctly
calculate the total number of tests executed. Previously, individual
rows were not shown in the test output if they passed, making such
calculations impossible.
The only change to the xunitxml output format is to correct a bug where
no test result was recorded for a test function if the last data row
was skipped and all other rows passed -- in which case the overall
result should be a pass. Note that there is also a pre-existing bug
in the xunit logger, where no result is reported if all rows are
skipped; that bug is unaffected by this commit.
Task-number: QTBUG-21848
Task-number: QTBUG-22124
Change-Id: I7e17177e10d6e89e55b9684c159bd506f21d002b
Reviewed-by: Ed Baak <ed.baak@nokia.com>
Use a standard path for filenames that appear in the selftest's expected
test data. This will make future patches smaller.
Change-Id: I04b2e739d261f80d20b834e5b33c5b6e88d26379
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
