[Development] Duplicated test data tags

[Milian Wolff]

On Donnerstag, 13. Oktober 2022 15:50:06 CEST Edward Welbourne via Development 
wrote:
> QTBUG-107185 revealed that QTest did not check for duplicated test data
> tags, i.e. parameters to newRow() / addRow(); when I looked at the
> implementation I found it also neglected to check for duplicated
> addColumn names.  So [0] sets out to fix that.
> 
> It turns out that Qt itself has "quite a lot" of instances of duplicate
> test data tags.  (I've only found one duplicate column, thankfully; but
> there may be more.)  So, for now, the fix merely produces a warning; and
> I do encourage all to watch out for "Duplicate data tag ... - please
> rename." messages in test output (once [0] has landed).  Likewise for
> similar with "column" in place of "tag".
> 
> [0] https://codereview.qt-project.org/c/qt/qtbase/+/436495
> 
> You can see from the branch it's the tip of, currently, some of the many
> cases of duplication we had before it brought them to my attention.
> There remain more even in qtbase and I haven't (for now, at least)
> looked further afield.
> 
> The present draft of that change has #if-ery to turn duplication of
> column or row names, in QTest data tables, at Qt 7, into a fatal error.
> How realistic do folk think it is that client code authors will respond
> to the warnings in time for that ?
> 
> I have, for now, included #if-ery complications that let you, when
> building QtTestLib, define Q_TEST_REJECT_DUPLICATE_ROW to 0 or 1 in the
> build system (and likewise for ..._COLUMN) to override the default
> behaviour (0 means warning only even for Qt 7; 1 means fatal even before
> Qt 7) but without any build infrastructure (yet) to set that.  Is this
> adequate or overkill; does anyone have a better suggestion ?

I have many times accidentally written bogus code that duplicated the tags. 
Getting a warning is useful, so thanks for working on that!

But we won't easily spot these in the thousands of lines of outputs a large 
test suite is generating. At the very least I would suggest something akin to 
QT_FATAL_WARNINGS that can be set to more easily spot faulty client code.

Cheers
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20221013/15c815ab/attachment.sig>