On 28/03/2024 10:36, Axel Spoerl via Development wrote:
Since _L1 usage is massive in corelib, I wonder whether there is a standard that everyone can apply when writing or reviewing autotests. If it exists and I have overlooked it, please forgive my negligence and point me to it.* What is the recommended way to construct a string in autotests? * Where to place "using namespace"? * Shall string constructions be fixed as a drive-by? IMHO, clarifying these questions generally helps and expedites code reviews.See https://codereview.qt-project.org/c/qt/qtbase/+/551645 <https://codereview.qt-project.org/c/qt/qtbase/+/551645?forceReload=true> as a recent example.
TL;DR: leave it alone.I don't think there is any specific guidance here. Autotests usually follow much more "relaxed" rules wrt the rest of Qt; APIs that are usually disabled or trigger deprecation warnings if called by library code "just work" when called from autotests.
IMHO, test code should be easy to write (we want people to write MORE test cases!) even if, pedantically, the APIs used in a test's source code aren't the Absolute Best™ available at the moment.
Therefore it becomes a matter of style, and of code evolution. You'll find a mix of styles (sometimes even in the same file) simply because some code predates the introduction of certain facilities (like the _L1 user-defined literal). Again I don't think there's anything wrong with it, *especially* in test code, and spending time to port these usages sounds counter-productive to me.
Even more specifically: 1) "how do we do strings in Qt" has been constantly changing (possibly in every single minor release of Qt), because we've been adding more and more features; and 2) strings are obviously used *everywhere*. Therefore, it's very easy to find code that doesn't use "the latest and the greatest" incantation to accomplish a given task. On top of this, add the massive mental burden of remembering which one even *is* the latest and the greatest.
And, in your case: you can just write QCOMPARE(str, "foo"), as there's a suitable qCompare overload.
My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence
smime.p7s
Description: S/MIME Cryptographic Signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
