[Development] Duplicated test data tags

[Milian Wolff]

On Freitag, 14. Oktober 2022 10:55:54 CEST Edward Welbourne wrote:
> Milian Wolff (Friday, 14 October 2022 3:00 AM)
> 
> >> 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.
> 
> Indeed, that strikes me as eminently plausible.
> Especially as one of the things I've been picking up on (and I've fixed
> various of them, at least in QtCore) as a result of chasing these down
> is that we have quite a few tests with QWARN messages, that really
> should be anticipated (so that the test fails if the warning isn't
> produced; and so that the test log isn't cluttered with the warnings)
> using QTest::ignoreWarning().
> 
> I should also take this opportunity to encourage all developers to watch
> out for QWARN messages in test output: if it's unexpected, it may be the
> symptom of a lurking bug; otherwise, its presence should be tested for,
> see preceding.  If the code under test fails to produce a warning that
> was expected, that's an issue the test should catch.
> 
> >> At the very least I would suggest something akin to QT_FATAL_WARNINGS
> >> that can be set to more easily spot faulty client code.
> 
> Perhaps, given the above, we should just encourage developers to use
> QT_FATAL_WARNINGS more often ?
> 
> I do note, however, that it seems not to have been documented; I shall
> add a doc update to my branch.

That is sadly not an option in many situations. The silencing of the warnings 
does not influence the fatal-abort to my knowledge? See 
`QMessageLogger::warning`:

```
void QMessageLogger::warning(const char *msg, ...) const
{
    va_list ap;
    va_start(ap, msg); // use variable arg list
    const QString message = qt_message(QtWarningMsg, context, msg, ap);
    va_end(ap);

    if (isFatal(QtWarningMsg))
        qt_message_fatal(QtWarningMsg, context, message);
}
```

So while `qt_message` is intercepted, the `qt_message_fatal` is not which then 
would kill the app even for "expected" warnings.

What's worse, there are many warnings where you don't know how many of them 
will occur. We e.g. run our unit test suite using the offscreen platform 
plugin and are drowning in warnings such as:

```
This plugin does not support setParent!
```

And so far I could not find a reliable way to prevent this. 

Similarly, we need a custom OpenGL profile which always triggers this warning 
when Qt WebEngine is also used:

```
An OpenGL Core Profile was requested, but it is not supported on the current 
platform. Falling back to a non-Core profile. Note that this might cause 
rendering issues.
```

Meaning: there are sadly some situations where warnings are emitted that you 
do not have control over. Meaning, Qt_FATAL_WARNINGS is sadly not an option 
today :(

> Mitch Curtis (14 October 2022 03:40) replied:
> > QTest::failOnWarning (introduced in 6.3) could also be used by tests
> > to make that warning fail the test:
> > 
> > https://doc.qt.io/qt-6/qtest.html#failOnWarning
> 
> True enough; but you would need to add that to the start of your _data()
> function; I think a global setting is more in line with what's needed.
> Fortunately we do have QT_FATAL_WARNINGS; I had forgotten about that.
> 
> So the question is: does it suffice to encourage developers to test with
> that enabled, or do we need something more specific to the particular
> issue of tag and column names in _data() functions ?
> 
> 	Eddy.


-- 
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/20221014/8d05061b/attachment.sig>