AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
67c877562b
qt5base-lts/tests/auto/testlib/selftests/expected_float.junitxml

308 lines
19 KiB
Plaintext
Raw Normal View History

generate_expected_output.py: update generated expected_* files In selftests.qrc, imposed alphabetic order (on stem of name, then on suffix, effectively treating . as sorting before any letter) while removing old tests and adding new tests and data. Updated all non-csv files and added many missing files. (Not clear on csv support status; the script seems to have dropped it after 5.6, but the test still uses it.) Left expected_crashes* alone (no new files added, no update to old) as I don't get results resembling those anticipated. Omitted printdatatagswithglobaltags, printdatatags due to dangling hspace on output lines, which upset sanity-bot. A change to the test cpp is needed to make it viable to skip that dangling hspace. Change-Id: Iab3fb626c44a91c249b2fb626c12c75ea0317098 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-07-29 11:18:24 +00:00
<?xml version="1.0" encoding="UTF-8" ?>
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
<testsuite name="tst_float" tests="6" failures="96" errors="0">
generate_expected_output.py: update generated expected_* files In selftests.qrc, imposed alphabetic order (on stem of name, then on suffix, effectively treating . as sorting before any letter) while removing old tests and adding new tests and data. Updated all non-csv files and added many missing files. (Not clear on csv support status; the script seems to have dropped it after 5.6, but the test still uses it.) Left expected_crashes* alone (no new files added, no update to old) as I don't get results resembling those anticipated. Omitted printdatatagswithglobaltags, printdatatags due to dangling hspace on output lines, which upset sanity-bot. A change to the test cpp is needed to make it viable to skip that dangling hspace. Change-Id: Iab3fb626c44a91c249b2fb626c12c75ea0317098 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-07-29 11:18:24 +00:00
<properties>
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
<property name="QTestVersion" value="@INSERT_QT_VERSION_HERE@"/>
<property name="QtVersion" value="@INSERT_QT_VERSION_HERE@"/>
<property name="QtBuild" value=""/>
generate_expected_output.py: update generated expected_* files In selftests.qrc, imposed alphabetic order (on stem of name, then on suffix, effectively treating . as sorting before any letter) while removing old tests and adding new tests and data. Updated all non-csv files and added many missing files. (Not clear on csv support status; the script seems to have dropped it after 5.6, but the test still uses it.) Left expected_crashes* alone (no new files added, no update to old) as I don't get results resembling those anticipated. Omitted printdatatagswithglobaltags, printdatatags due to dangling hspace on output lines, which upset sanity-bot. A change to the test cpp is needed to make it viable to skip that dangling hspace. Change-Id: Iab3fb626c44a91c249b2fb626c12c75ea0317098 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-07-29 11:18:24 +00:00
</properties>
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
<testcase name="initTestCase" result="pass"/>
<testcase name="doubleComparisons" result="fail">
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 1
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 3" tag="should FAIL 1"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 1e&#x002D;07
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 3e&#x002D;07" tag="should FAIL 2"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 999999999999
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 999999999998" tag="should FAIL 3"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
QCOMPARE: treat values as equal if qFuzzyIsNull(each) We hope this shall avoid some flaky failures noticed in quick tests, e.g. tst_QQuickMenu::Material::subMenuPosition(cascading,flip) was recently seen failing with 3.88e-11 != 0. This required some revision to test data in the testlib selftest for floats; the resulting expected output differs in details but not in which tests pass or fail. QEMU, naturally, made life difficult, requiring special-case code in the test-driver. [ChangeLog][QtTestLib][QCOMPARE] QCOMPARE() now treats its values as equal when qFuzzyIsNull() is true for both of them. Change-Id: Icc6ad5164b609937eddbe39cc69120f0abf0f3b4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2020-04-15 11:10:31 +00:00
Actual (operandLeft) : 1e&#x002D;12
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 9.99999999999e&#x002D;13" tag="should FAIL 4"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 9.99999999999e+306
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 9.99999999997e+306" tag="should FAIL 5"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : nan
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 0" tag="should FAIL: NaN != 0"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 0
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): nan" tag="should FAIL: 0 != NaN"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : nan
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 1" tag="should FAIL: NaN != 1"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 1
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): nan" tag="should FAIL: 1 != NaN"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: inf != &#x002D;inf"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: &#x002D;inf != inf"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): nan" tag="should FAIL: inf != nan"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : nan
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: nan != inf"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): nan" tag="should FAIL: &#x002D;inf != nan"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : nan
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: nan != &#x002D;inf"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 0" tag="should FAIL: inf != 0"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 0
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: 0 != inf"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 0" tag="should FAIL: &#x002D;inf != 0"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 0
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: 0 != &#x002D;inf"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 1" tag="should FAIL: inf != 1"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 1
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: 1 != inf"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 1" tag="should FAIL: &#x002D;inf != 1"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 1
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: 1 != &#x002D;inf"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 1.79769313486e+308" tag="should FAIL: inf != max"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;1.79769313486e+308" tag="should FAIL: inf != &#x002D;max"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 1.79769313486e+308
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: max != inf"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;1.79769313486e+308
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: &#x002D;max != inf"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 1.79769313486e+308" tag="should FAIL: &#x002D;inf != max"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;1.79769313486e+308" tag="should FAIL: &#x002D;inf != &#x002D;max"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 1.79769313486e+308
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: max != &#x002D;inf"/>
<failure result="fail" message="Compared doubles are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;1.79769313486e+308
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: &#x002D;max != &#x002D;inf"/>
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
</testcase>
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
<testcase name="floatComparisons" result="fail">
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
generate_expected_output.py: update generated expected_* files In selftests.qrc, imposed alphabetic order (on stem of name, then on suffix, effectively treating . as sorting before any letter) while removing old tests and adding new tests and data. Updated all non-csv files and added many missing files. (Not clear on csv support status; the script seems to have dropped it after 5.6, but the test still uses it.) Left expected_crashes* alone (no new files added, no update to old) as I don't get results resembling those anticipated. Omitted printdatatagswithglobaltags, printdatatags due to dangling hspace on output lines, which upset sanity-bot. A change to the test cpp is needed to make it viable to skip that dangling hspace. Change-Id: Iab3fb626c44a91c249b2fb626c12c75ea0317098 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-07-29 11:18:24 +00:00
Actual (operandLeft) : 1
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 3" tag="should FAIL 1"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
QCOMPARE: treat values as equal if qFuzzyIsNull(each) We hope this shall avoid some flaky failures noticed in quick tests, e.g. tst_QQuickMenu::Material::subMenuPosition(cascading,flip) was recently seen failing with 3.88e-11 != 0. This required some revision to test data in the testlib selftest for floats; the resulting expected output differs in details but not in which tests pass or fail. QEMU, naturally, made life difficult, requiring special-case code in the test-driver. [ChangeLog][QtTestLib][QCOMPARE] QCOMPARE() now treats its values as equal when qFuzzyIsNull() is true for both of them. Change-Id: Icc6ad5164b609937eddbe39cc69120f0abf0f3b4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2020-04-15 11:10:31 +00:00
Actual (operandLeft) : 1e&#x002D;05
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 3e&#x002D;05" tag="should FAIL 2"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 99999
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 99998" tag="should FAIL 3"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
QCOMPARE: treat values as equal if qFuzzyIsNull(each) We hope this shall avoid some flaky failures noticed in quick tests, e.g. tst_QQuickMenu::Material::subMenuPosition(cascading,flip) was recently seen failing with 3.88e-11 != 0. This required some revision to test data in the testlib selftest for floats; the resulting expected output differs in details but not in which tests pass or fail. QEMU, naturally, made life difficult, requiring special-case code in the test-driver. [ChangeLog][QtTestLib][QCOMPARE] QCOMPARE() now treats its values as equal when qFuzzyIsNull() is true for both of them. Change-Id: Icc6ad5164b609937eddbe39cc69120f0abf0f3b4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2020-04-15 11:10:31 +00:00
Actual (operandLeft) : 1.00001e&#x002D;05
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 9.9999e&#x002D;06" tag="should FAIL 4"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 9.9999e+37
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 9.9997e+37" tag="should FAIL 5"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : nan
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 0" tag="should FAIL: NaN != 0"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 0
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): nan" tag="should FAIL: 0 != NaN"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : nan
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 1" tag="should FAIL: NaN != 1"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 1
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): nan" tag="should FAIL: 1 != NaN"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: inf != &#x002D;inf"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: &#x002D;inf != inf"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): nan" tag="should FAIL: inf != nan"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : nan
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: nan != inf"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): nan" tag="should FAIL: &#x002D;inf != nan"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : nan
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: nan != &#x002D;inf"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 0" tag="should FAIL: inf != 0"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 0
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: 0 != inf"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 0" tag="should FAIL: &#x002D;inf != 0"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 0
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: 0 != &#x002D;inf"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 1" tag="should FAIL: inf != 1"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 1
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: 1 != inf"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 1" tag="should FAIL: &#x002D;inf != 1"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 1
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: 1 != &#x002D;inf"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 3.40282e+38" tag="should FAIL: inf != max"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;3.40282e+38" tag="should FAIL: inf != &#x002D;max"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 3.40282e+38
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: max != inf"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;3.40282e+38
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: &#x002D;max != inf"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 3.40282e+38" tag="should FAIL: &#x002D;inf != max"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;3.40282e+38" tag="should FAIL: &#x002D;inf != &#x002D;max"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : 3.40282e+38
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: max != &#x002D;inf"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
Actual (operandLeft) : &#x002D;3.40282e+38
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: &#x002D;max != &#x002D;inf"/>
generate_expected_output.py: update generated expected_* files In selftests.qrc, imposed alphabetic order (on stem of name, then on suffix, effectively treating . as sorting before any letter) while removing old tests and adding new tests and data. Updated all non-csv files and added many missing files. (Not clear on csv support status; the script seems to have dropped it after 5.6, but the test still uses it.) Left expected_crashes* alone (no new files added, no update to old) as I don't get results resembling those anticipated. Omitted printdatatagswithglobaltags, printdatatags due to dangling hspace on output lines, which upset sanity-bot. A change to the test cpp is needed to make it viable to skip that dangling hspace. Change-Id: Iab3fb626c44a91c249b2fb626c12c75ea0317098 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-07-29 11:18:24 +00:00
</testcase>
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
<testcase name="float16Comparisons" result="fail">
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
Add qfloat16 support to QCOMPARE Change-Id: Ide06f215a888328308a06e7e48edd666f790a5f0 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2018-11-09 13:05:35 +00:00
Actual (operandLeft) : 1
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 3" tag="should FAIL 1"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QCOMPARE: treat values as equal if qFuzzyIsNull(each) We hope this shall avoid some flaky failures noticed in quick tests, e.g. tst_QQuickMenu::Material::subMenuPosition(cascading,flip) was recently seen failing with 3.88e-11 != 0. This required some revision to test data in the testlib selftest for floats; the resulting expected output differs in details but not in which tests pass or fail. QEMU, naturally, made life difficult, requiring special-case code in the test-driver. [ChangeLog][QtTestLib][QCOMPARE] QCOMPARE() now treats its values as equal when qFuzzyIsNull() is true for both of them. Change-Id: Icc6ad5164b609937eddbe39cc69120f0abf0f3b4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2020-04-15 11:10:31 +00:00
Actual (operandLeft) : 0.000999
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 0.003" tag="should FAIL 2"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
Add qfloat16 support to QCOMPARE Change-Id: Ide06f215a888328308a06e7e48edd666f790a5f0 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2018-11-09 13:05:35 +00:00
Actual (operandLeft) : 98
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 99" tag="should FAIL 3"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QCOMPARE: treat values as equal if qFuzzyIsNull(each) We hope this shall avoid some flaky failures noticed in quick tests, e.g. tst_QQuickMenu::Material::subMenuPosition(cascading,flip) was recently seen failing with 3.88e-11 != 0. This required some revision to test data in the testlib selftest for floats; the resulting expected output differs in details but not in which tests pass or fail. QEMU, naturally, made life difficult, requiring special-case code in the test-driver. [ChangeLog][QtTestLib][QCOMPARE] QCOMPARE() now treats its values as equal when qFuzzyIsNull() is true for both of them. Change-Id: Icc6ad5164b609937eddbe39cc69120f0abf0f3b4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2020-04-15 11:10:31 +00:00
Actual (operandLeft) : 0.00101
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 0.00099" tag="should FAIL 4"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : 5.94e+04
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 5.88e+04" tag="should FAIL 5"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : nan
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 0" tag="should FAIL: NaN != 0"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : 0
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): nan" tag="should FAIL: 0 != NaN"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : nan
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 1" tag="should FAIL: NaN != 1"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : 1
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): nan" tag="should FAIL: 1 != NaN"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: inf != &#x002D;inf"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: &#x002D;inf != inf"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): nan" tag="should FAIL: inf != nan"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : nan
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: nan != inf"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): nan" tag="should FAIL: &#x002D;inf != nan"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : nan
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: nan != &#x002D;inf"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 0" tag="should FAIL: inf != 0"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : 0
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: 0 != inf"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 0" tag="should FAIL: &#x002D;inf != 0"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : 0
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: 0 != &#x002D;inf"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 1" tag="should FAIL: inf != 1"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : 1
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: 1 != inf"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 1" tag="should FAIL: &#x002D;inf != 1"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : 1
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: 1 != &#x002D;inf"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 6.55e+04" tag="should FAIL: inf != max"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;6.55e+04" tag="should FAIL: inf != &#x002D;max"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : 6.55e+04
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: max != inf"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : &#x002D;6.55e+04
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): inf" tag="should FAIL: &#x002D;max != inf"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): 6.55e+04" tag="should FAIL: &#x002D;inf != max"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : &#x002D;inf
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;6.55e+04" tag="should FAIL: &#x002D;inf != &#x002D;max"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : 6.55e+04
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: max != &#x002D;inf"/>
<failure result="fail" message="Compared qfloat16s are not the same (fuzzy compare)
QtTestLib: handle float16 the same as double and float In QCOMPARE, handle NaNs and infinities the way tests want them handled, rather than by strict IEEE rules. In particular, if a test expects NaN, this lets it treat that just like any other expected value, despite NaN != NaN as float16 values. Likewise, format infinities and NaNs specially in toString() so that they're reported consistently. Enable the qfloat16 tests that depend on this QCOMPARE() behavior. Refise the testlib selftest's float test to test qfloat16 the same way it tests float and double (and format the test the same way). This is a follow-up to 37f617c405a. Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-11-21 13:36:08 +00:00
Actual (operandLeft) : &#x002D;6.55e+04
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (operandRight): &#x002D;inf" tag="should FAIL: &#x002D;max != &#x002D;inf"/>
Add qfloat16 support to QCOMPARE Change-Id: Ide06f215a888328308a06e7e48edd666f790a5f0 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2018-11-09 13:05:35 +00:00
</testcase>
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
<testcase name="compareFloatTests" result="fail">
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
generate_expected_output.py: update generated expected_* files In selftests.qrc, imposed alphabetic order (on stem of name, then on suffix, effectively treating . as sorting before any letter) while removing old tests and adding new tests and data. Updated all non-csv files and added many missing files. (Not clear on csv support status; the script seems to have dropped it after 5.6, but the test still uses it.) Left expected_crashes* alone (no new files added, no update to old) as I don't get results resembling those anticipated. Omitted printdatatagswithglobaltags, printdatatags due to dangling hspace on output lines, which upset sanity-bot. A change to the test cpp is needed to make it viable to skip that dangling hspace. Change-Id: Iab3fb626c44a91c249b2fb626c12c75ea0317098 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-07-29 11:18:24 +00:00
Actual (t1): 1
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (t3): 3" tag="1e0"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
QCOMPARE: treat values as equal if qFuzzyIsNull(each) We hope this shall avoid some flaky failures noticed in quick tests, e.g. tst_QQuickMenu::Material::subMenuPosition(cascading,flip) was recently seen failing with 3.88e-11 != 0. This required some revision to test data in the testlib selftest for floats; the resulting expected output differs in details but not in which tests pass or fail. QEMU, naturally, made life difficult, requiring special-case code in the test-driver. [ChangeLog][QtTestLib][QCOMPARE] QCOMPARE() now treats its values as equal when qFuzzyIsNull() is true for both of them. Change-Id: Icc6ad5164b609937eddbe39cc69120f0abf0f3b4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2020-04-15 11:10:31 +00:00
Actual (t1): 1e&#x002D;05
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (t3): 3e&#x002D;05" tag="1e&#x002D;5"/>
<failure result="fail" message="Compared floats are not the same (fuzzy compare)
generate_expected_output.py: update generated expected_* files In selftests.qrc, imposed alphabetic order (on stem of name, then on suffix, effectively treating . as sorting before any letter) while removing old tests and adding new tests and data. Updated all non-csv files and added many missing files. (Not clear on csv support status; the script seems to have dropped it after 5.6, but the test still uses it.) Left expected_crashes* alone (no new files added, no update to old) as I don't get results resembling those anticipated. Omitted printdatatagswithglobaltags, printdatatags due to dangling hspace on output lines, which upset sanity-bot. A change to the test cpp is needed to make it viable to skip that dangling hspace. Change-Id: Iab3fb626c44a91c249b2fb626c12c75ea0317098 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-07-29 11:18:24 +00:00
Actual (t1): 1e+07
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
Expected (t3): 3e+07" tag="1e+7"/>
generate_expected_output.py: update generated expected_* files In selftests.qrc, imposed alphabetic order (on stem of name, then on suffix, effectively treating . as sorting before any letter) while removing old tests and adding new tests and data. Updated all non-csv files and added many missing files. (Not clear on csv support status; the script seems to have dropped it after 5.6, but the test still uses it.) Left expected_crashes* alone (no new files added, no update to old) as I don't get results resembling those anticipated. Omitted printdatatagswithglobaltags, printdatatags due to dangling hspace on output lines, which upset sanity-bot. A change to the test cpp is needed to make it viable to skip that dangling hspace. Change-Id: Iab3fb626c44a91c249b2fb626c12c75ea0317098 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-07-29 11:18:24 +00:00
</testcase>
testlib: Output JUnitXML attributes in right order The attributes are, like the elements, maintained in reverse order in the underlying QTestCoreList, so we need to iterate them backwards when printing out the resulting XML to reflect the order they were added. This results in e.g.: <testcase name="passingBenchmark" result="pass"> Instead of: <testcase result="pass" name="passingBenchmark"> Change-Id: Ic2eeab8de05ffedd0c41977358d5b40ff77878b1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-07-21 23:38:42 +00:00
<testcase name="cleanupTestCase" result="pass"/>
generate_expected_output.py: update generated expected_* files In selftests.qrc, imposed alphabetic order (on stem of name, then on suffix, effectively treating . as sorting before any letter) while removing old tests and adding new tests and data. Updated all non-csv files and added many missing files. (Not clear on csv support status; the script seems to have dropped it after 5.6, but the test still uses it.) Left expected_crashes* alone (no new files added, no update to old) as I don't get results resembling those anticipated. Omitted printdatatagswithglobaltags, printdatatags due to dangling hspace on output lines, which upset sanity-bot. A change to the test cpp is needed to make it viable to skip that dangling hspace. Change-Id: Iab3fb626c44a91c249b2fb626c12c75ea0317098 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-07-29 11:18:24 +00:00
<system-err/>
</testsuite>
Reference in New Issue Copy Permalink