Qt Contributors Summit 2022 - Program/Directions for QTestLib messages: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Added session notes)
 
Line 11: Line 11:
==Notes==
==Notes==


(Taken by XXX)
(Taken by Samuel Gaist)


===Title===
=== References ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
https://bugreports.qt.io/browse/QTBUG-94476


===Title===
https://bugreports.qt.io/browse/QTBUG-101725


Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
=== Status ===
QtTest does not fulfill the "simple to use" mantra


Formatting messages is not easily done


===Title===
Current use of constchar* trigger lots of qPrintable in user code.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
 
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