[Development] QtScript review required: https://codereview.qt-project.org/253585
There's a patch for QtScript that has gone unreviewed for close to 2 months now. Can someone make a yay or nay decision on it? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros
On 05/04/2019 10.49, Matthew Woehlke wrote:
> IMNSHO, I think Qt would do well to take a close and careful look at
> Google Test, which IMO has a much better design, at least as far as how
> test assertions are handled.
>
> In particular, I miss having a distinction between fatal and non-fatal
> assertions, which, aside from their own inherent value, I think would be
> a better solution to this problem. These could be combined with a macro
> to invoke a helper function which would a) add additional context if the
> helper function produces *any* test output (I'm thinking this should
> include use of QDebug), and b) optionally¹ abort the caller² if a fatal
> assertion has occurred.
To elaborate on that, I would suggest having at least three assertions:
1. Evaluate an expression's truthiness (expecting true).
2. Compare a computed value to an expected value (expecting equality).
3. Execute a statement (expecting no failed assertions in the process).
Each of these should *additionally* come in both fatal and non-fatal
forms. A fatal form triggers a `return` in the containing scope. A
non-fatal form merely logs the failure and continues on. A test fails if
*any* assertion failed during its execution.
The fatal forms of (1) and (2) are equivalent to QVERIFY and QCOMPARE,
respectively. (3) can and should be used to invoke "helper functions"
and obviates the need to use exceptions. Note however that it doesn't
*need* to be used, since the helper can still contain assertions which
will still cause the test to fail. However, using (3) will also log the
call site if the helper has failing assertions, and is required for
assertions in the helper to abort execution in the caller.
For example:
1 void helper()
2 {
3 QVERIFY(false);
4 abort(); // won't get here
5 }
6
7 void Test::testcase()
8 {
9 QTRY_CALL(helper());
10 QCALL(helper());
11 abort(); // won't get here
12 }
...would produce something like:
FAIL! ...
Loc: sample.cpp(3)
Via: sample.cpp(9)
FAIL! ...
Loc: sample.cpp(3)
Via: sample.cpp(10)
--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros
On 02/04/2019 11.14, 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. > > [...] > > I'm curious what other people think about [throwing exceptions > instead]? IMNSHO, I think Qt would do well to take a close and careful look at Google Test, which IMO has a much better design, at least as far as how test assertions are handled. In particular, I miss having a distinction between fatal and non-fatal assertions, which, aside from their own inherent value, I think would be a better solution to this problem. These could be combined with a macro to invoke a helper function which would a) add additional context if the helper function produces *any* test output (I'm thinking this should include use of QDebug), and b) optionally¹ abort the caller² if a fatal assertion has occurred. (¹ Why optional? I've found it extremely useful to be able to use "fatal" assertions to abort a sub-block of a unit test, such as a helper function. So useful, in fact, that I've adopted a regular pattern of immediately-invoked lambdas for the sole purpose of controlling "how much" of a test case a fatal assertion aborts.) (² How? By recording somewhere that a fatal exception has occurred, and having the invocation wrapper check that and abort the caller. Note that this needs to distinguish between "fatal exception(s) happened previously" and "new fatal exception(s) happened in what I called".) -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Shadertools repo request and some words about state of graphics
On 2/4/19 11:14 pm, Laszlo Agocs wrote: As discussed at https://wiki.qt.io/QtCS2018_Graphics_Vision_2020 Qt 6 will do away with the hard OpenGL dependency in most, if not all, of its modules. This is achieved via a small abstraction layer, currently called the Qt Rendering Hardware Interface, with backends for Vulkan, Metal, Direct 3D 11, and OpenGL (ES) 2.x(+ some 3.x extensions) at the moment. Please keep in mind WebGL as well. It's a bit more strict than OpenGL ES, and has slightly different rules. https://www.khronos.org/registry/webgl/specs/latest/1.0/#6 https://www.khronos.org/registry/webgl/specs/latest/2.0/#5 On WebAssembly, all opengl calls get wrapped into WebGL and the slightly different rules sometimes causes issues. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros
Il 05/04/19 10:29, Mitch Curtis ha scritto: To take the obvious one first: anyone using their own custom macros in helpers shouldn't be affected (that's me, currently). But which custom macros, exactly? If your macros expand to private APIs usage, we can break that anytime we want. Anyone (incorrectly) using Qt macros in helpers shouldn't be affected so long as exceptions are enabled; their tests will just correctly terminate early upon failures in those helpers now. Exactly, but this is unsupported right now, so we can do a SIC. (If it's behind a opt-in / opt-out mechanism, even better). Any tests with exceptions explicitly disabled would fail to compile. That might be the biggest issue? Hopefully we can detect it (e.g. GCC/Clang define __EXCEPTIONS when exceptions are enabled), and make our macros return instead of throw, i.e. keep the current behaviour and the current limitation of being used only directly from a testcase function. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@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 smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros
> -Original Message- > From: Giuseppe D'Angelo > Sent: Friday, 5 April 2019 12:39 AM > To: Mitch Curtis ; development@qt-project.org > Subject: Re: [Development] Supporting helper functions in auto tests by > providing throwing Qt Test macros > > Il 03/04/19 13:58, Mitch Curtis ha scritto: > >>> 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. > >> > >> To me, a change like this (making the existing macros throw) seems more > like > >> a Qt 6 thing, but I could be wrong. I only went with new macros because I > >> was afraid of breaking stuff, but yeah, just changing the existing ones > would > >> be ideal. > > If you expect Qt 6 to be as much source compatible with Qt 5 as > possible, then you can make this change right now as much you can make > it in Qt 6. > > So, let's discuss: what breaks if you make today's macros throw instead > of return? To take the obvious one first: anyone using their own custom macros in helpers shouldn't be affected (that's me, currently). Anyone using Qt macros as they're supposed to be used shouldn't be affected so long as we correctly catch the exceptions that we throw. :) Anyone (incorrectly) using Qt macros in helpers shouldn't be affected so long as exceptions are enabled; their tests will just correctly terminate early upon failures in those helpers now. Anyone who is throwing exceptions as part of their tests could be affected, I suppose, though your point about handling exceptions correctly and/or the opt-in suggestion (e.g. a QTEST_THROWING_MAIN) seems like it would cover it. Any tests with exceptions explicitly disabled would fail to compile. That might be the biggest issue? > > >> > >>> 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. > >> > >> Hmm, I hadn't thought about invoke()... hopefully that's not an > (unsolvable) > >> issue, otherwise it kinda ruins this whole idea. > > As I said, I believe these codepaths support exceptions (but it's not > exactly documented). If they don't we can should fix them to do so. > > > >>> 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()). > >> > >> What kind of opt-in mechanism did you have in mind? > > Anything that is suitable -- env variables, a different macro to create > the test's main, something to set in your initTestCase(), a CONFIG > switch in your .pro, etc. > > Cheers, > -- > Giuseppe D'Angelo | giuseppe.dang...@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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
