Qt-contributors-summit-2014-Qs2014QmlTest: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
m (Categorize)
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
[[Category:QtCS2014]]
=QmlTest=
=QmlTest=


Michał Sawicz, Michael Zanetti
Michał Sawicz, Michael Zanetti


We’ve been rather happy with qmltestrunner, we’d like to show our approach to combining auto and manual test <span class="caps">QML</span> code. The thing we’ve been struggling with is measuring coverage for <span class="caps">QML</span>, so that’s what we’d like to brainstorm about.
We've been rather happy with qmltestrunner, we'd like to show our approach to combining auto and manual test <span class="caps">QML</span> code. The thing we've been struggling with is measuring coverage for <span class="caps">QML</span>, so that's what we'd like to brainstorm about.


Some notes:
Some notes:


* It’s hard to measure test coverage with <span class="caps">QML</span> because:
* It's hard to measure test coverage with <span class="caps">QML</span> because:
*# Declarative code doesn’t really execute anything – it “creates”
*# Declarative code doesn't really execute anything – it "creates"
*# eval() breaks coverage metrics by adding code at runtime
*# eval() breaks coverage metrics by adding code at runtime
*# standard coverage tools don’t know about <span class="caps">QML</span>/JS
*# standard coverage tools don't know about <span class="caps">QML</span>/JS
* We can deal with declarative code by measuring which types were instantiated.
* We can deal with declarative code by measuring which types were instantiated.
* We can deal with the eval() problem by agreeing on not to use eval().
* We can deal with the eval() problem by agreeing on not to use eval().
Line 17: Line 19:
* Multi-engine profiling is currently not possible with the command line profiler but could be done using EngineControl.
* Multi-engine profiling is currently not possible with the command line profiler but could be done using EngineControl.


(Something is wrong with command line handling and the test runner in conjunction with qmlprofiler – it didn’t work in the demo.)
(Something is wrong with command line handling and the test runner in conjunction with qmlprofiler – it didn't work in the demo.)

Latest revision as of 17:38, 6 January 2017

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

QmlTest

Michał Sawicz, Michael Zanetti

We've been rather happy with qmltestrunner, we'd like to show our approach to combining auto and manual test QML code. The thing we've been struggling with is measuring coverage for QML, so that's what we'd like to brainstorm about.

Some notes:

  • It's hard to measure test coverage with QML because:
    1. Declarative code doesn't really execute anything – it "creates"
    2. eval() breaks coverage metrics by adding code at runtime
    3. standard coverage tools don't know about QML/JS
  • We can deal with declarative code by measuring which types were instantiated.
  • We can deal with the eval() problem by agreeing on not to use eval().
  • We can try to use the QML profiler as tool to measure coverage.
  • The QML profiler currently measures only function calls. We want branch/condition or line coverage. This would be possible by collecting more data with the profiler, at the cost of a higher impact on performance. As that is not a good idea for profiling it should be optional.
  • Multi-engine profiling is currently not possible with the command line profiler but could be done using EngineControl.

(Something is wrong with command line handling and the test runner in conjunction with qmlprofiler – it didn't work in the demo.)