Qt Contributors Summit 2022 - Program/Directions for QTestLib messages: Difference between revisions
m (CristianMaureiraFredes moved page Directions for QTestLib messages to Qt Contributors Summit 2022 - Program/Directions for QTestLib messages) |
(Added session notes) |
||
Line 11: | Line 11: | ||
==Notes== | ==Notes== | ||
(Taken by | (Taken by Samuel Gaist) | ||
=== | === References === | ||
https://bugreports.qt.io/browse/QTBUG-94476 | |||
https://bugreports.qt.io/browse/QTBUG-101725 | |||
=== Status === | |||
QtTest does not fulfill the "simple to use" mantra | |||
Formatting messages is not easily done | |||
=== | Current use of constchar* trigger lots of qPrintable in user code. | ||
UTF-16 printf is under control but not for the 8bit based character sets. | |||
=== Brainstorming === | |||
Should we go with std::format ? Requires C++20 | |||
varargs ? | |||
QAnyStringView ? | |||
=== Options === | |||
- Ideally something that is feature selectable | |||
- Consistency: addRow uses printf style | |||
Counterargument: | |||
- printf style is limited to builtin types | |||
- lots of code would need to be changed | |||
- Add "XXX_PRINTF" variants ? | |||
It's an option yes | |||
- Why not both? `QVERIFY_PRINTF(QAnyStringView, ...)` ? is it because we don't have formatting support for QAnyStringView ? | |||
Answer: yes and yes | |||
- Other suggestions: use qDebug ? | |||
Thiago: rather not, as it would make QtTest depend on QtCore and the later could break the former. | |||
QAnyStringView and the printf style in that order would be a good way to go. | |||
Either have overloads or two set of macros | |||
=== Discussions extracts === | |||
Q: We can repurpose QVERIFY2 for it and simply add QSKIP2 and QEXPECT_FAIL2 | |||
A: would rather not have XXX2 and even remove the ones we have if possible. | |||
Q: and for user-defined types? do you have a format string accepting the usual formatting, but _also_ accept %s and for user-defined types goes through QTest::toString? | |||
A: Does not change for current user, we add a new option for user. | |||
A: printf is known to user which is good | |||
Q: QVERIFYF(cond, "%0s", toString(enum)); "0 asks the backend to delete" ? | |||
A: People will get that wrong | |||
QAnyStringView preserves the encoding and the conversion will only happens once | |||
== Summary and accepted proposition == | |||
Going beyond the current propositions would likely end up with a large rewrite or a new layer for formatting to support custom types. | |||
- Add QAnyStringView for current macros | |||
- Add new macros for printf style |
Latest revision as of 07:42, 8 June 2022
Session Summary
Should QSKIP, QVERIFY2, etc. become printf-style to avoid formatting (asprintf(), arg()) entirely, or should they have QAnyStringView arguments to avoid all the toLocal8Bit().constData()? Can we have both?
Session Owners
- Marc Mutz
Notes
(Taken by Samuel Gaist)
References
https://bugreports.qt.io/browse/QTBUG-94476
https://bugreports.qt.io/browse/QTBUG-101725
Status
QtTest does not fulfill the "simple to use" mantra
Formatting messages is not easily done
Current use of constchar* trigger lots of qPrintable in user code.
UTF-16 printf is under control but not for the 8bit based character sets.
Brainstorming
Should we go with std::format ? Requires C++20
varargs ?
QAnyStringView ?
Options
- Ideally something that is feature selectable
- Consistency: addRow uses printf style
Counterargument:
- printf style is limited to builtin types
- lots of code would need to be changed
- Add "XXX_PRINTF" variants ?
It's an option yes
- Why not both? `QVERIFY_PRINTF(QAnyStringView, ...)` ? is it because we don't have formatting support for QAnyStringView ?
Answer: yes and yes
- Other suggestions: use qDebug ?
Thiago: rather not, as it would make QtTest depend on QtCore and the later could break the former.
QAnyStringView and the printf style in that order would be a good way to go.
Either have overloads or two set of macros
Discussions extracts
Q: We can repurpose QVERIFY2 for it and simply add QSKIP2 and QEXPECT_FAIL2
A: would rather not have XXX2 and even remove the ones we have if possible.
Q: and for user-defined types? do you have a format string accepting the usual formatting, but _also_ accept %s and for user-defined types goes through QTest::toString?
A: Does not change for current user, we add a new option for user.
A: printf is known to user which is good
Q: QVERIFYF(cond, "%0s", toString(enum)); "0 asks the backend to delete" ?
A: People will get that wrong
QAnyStringView preserves the encoding and the conversion will only happens once
Summary and accepted proposition
Going beyond the current propositions would likely end up with a large rewrite or a new layer for formatting to support custom types.
- Add QAnyStringView for current macros
- Add new macros for printf style