[Development] Supporting helper functions in auto tests by providing throwing Qt Test macros
giuseppe.dangelo at kdab.com
Wed Apr 3 13:21:18 CEST 2019
Il 02/04/19 17:14, Mitch Curtis ha scritto:
> 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.
I may like the overall approach. However, this would imply that such
tests require exceptions / RTTI turned on inside QtTestLib / user code;
is it "OK" in the grand scheme of things?
I have a question regarding this particular implementation, that is, why
adding dedicated testing functions? Can't you "simply" change the
currently existing QVERIFY/QCOMPARE to throw exceptions in case of
failure, instead of returning from the current test function? This would
achieve major consistency -- simply use the same functions everywhere,
no matter what.
This idea isn't failproof, as:
1) it requires the exception to propagate through a direct
QMetaObject::invoke (that is, whatever mechanism testlib uses to invoke
the test functions); but that should be already supported and tested, even.
2) it causes a minor SC in case the user was doing it wrong -- "catching
all", without rethrowing an unknown exception type. Before, a failing
test would simply return. With this idea, it would throw, and the
exception could be caught by the catch all and not used to block the
execution of the current test function.
The last can be solved in a very simple way (e.g. make this mechanism
opt-in; and also provide something to the user to test if the current
catch-all is a Qt test failure, via std::current_exception()).
My 2 c,
Giuseppe D'Angelo | giuseppe.dangelo at 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 - The Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4007 bytes
Desc: Firma crittografica S/MIME
More information about the Development