Qt Contributors Summit 2022 - Program/Directions for QTestLib messages

From Qt Wiki
Jump to navigation Jump to search

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


(Taken by Samuel Gaist)





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.


Should we go with std::format ? Requires C++20

varargs ?

QAnyStringView ?


- Ideally something that is feature selectable

- Consistency: addRow uses printf style


   - 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