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

Mitch Curtis mitch.curtis at qt.io
Tue Apr 2 17:14:38 CEST 2019

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.

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.

I looked into this briefly during the last hackathon we had, and from what I found, throwing an exception was the best approach:


Quoting the commit message here:

    WIP: Add _THROW variants to testlib macros

    This allows using Qt Test macros in helper functions, avoiding the need
    to write a lot of boilerplate code as seen with alternative approaches.

    The output for a failed test where a helper was called:

       FAIL!  : tst_App::openClose(ImageType) 'animationPanel->isVisible()' returned FALSE. ()
          Loc: [/home/mitch/dev/slate/tests/shared/testhelper.cpp(1990)]
       WARNING: tst_App::openClose(ImageType) createNewProject(projectType)
          Loc: [/home/mitch/dev/slate/tests/auto/tst_app.cpp(258)]

    The first two lines is the location of the failure in the helper,
    and the second two are the location of the call site of the helper.

    - Look into ways of reducing the output or making it clear that one
      part is the failure site and the other is the call site
    - Add tests
      - Test that uncaught exception (i.e. missing QCHECK_EXCEPTION) is caught
        and handled by the test runner

Oh, and throwing an exception like this should be fine since it's not travelling through Qt code.

I'm curious what other people think about this idea?

More information about the Development mailing list