[Development] Supporting helper functions in auto tests by providing throwing Qt Test macros

[Edward Welbourne]

On 4/2/19 5:14 PM, Mitch Curtis wrote:
>> As described in https://bugreports.qt.io/browse/QTBUG-66320, currently
>> Qt users are on their own if they want to call helper functions that
>> can fail a test. The reason is documented:
>>
>>      Note: This macro can only be used in a test function that is
>>      invoked by the test framework.

This note is not strictly true.  You can use it in any function that
returns void.  However, the *caller* won't return in response to it,
which means it doesn't work *fully* in a helper.

>> A common workaround for this is to make the helper function return a
>> bool indicating success or failure, and pass in a QString reference
>> which is set to the failure message (if any).
>>
>> I don't know how many people reading this have written comprehensive
>> auto tests for an application, but not having helper functions is just
>> not an option if you want maintainable code.

Joerg Bornemann (3 April 2019 09:55) replied
> This is massively annoying, and also a reason for
>    - either writing longish macros that should be functions instead
>    - duplicated code in tests.

For reference, you can have a void helper function (using "out
parameters" for anything it needs to return) and, immediately after the
call to it

  if (QTest::currentTestFailed())
      return;

in its caller.  We do this in some of the network tests where async
things are happening and a slot that our test isn't calling directly is
the only place we can detect certain failures.

That could perfectly readily be packaged as a macro, of course; e.g., by
analogy with Mitch's patch,

  #define QCHECK_EVAL(code) do { code; \
          if (QTest::currentTestFailed()) \
              return; \
      } while (0)

However, an exception-based approach would have the virtue of letting
one call helper functions that return values of whatever types one likes
(without having to resort to "out parameters"), which would surely lead
to nicer code.

	Eddy.