UbuntuTestCase provides a flick() function whose main purpose is to produce a flick event when executed on Flickable.
I noticed that this does not always happen, causing flakiness of some of the UITK tests (in my case, it's the Scrollbar/ScrollView tests I'm working on)
Here is a test case that reproduces the issue, once every 10-200 runs, depending on the configuration (I use a simple script to run it until it fails)
Please note that uncommenting the debug lines such as onMovingChanged onFlickingChanged will make it harder to reproduce the bug.
Enabling QT_LOGGING_RULES="qt.quick.mouse.debug=true" or onContentYChanged will make it even harder.
function setupSignalSpy(spy, target, signalName) { spy.clear()
//reset signalName otherwise it will look for the old signalName in the new target spy.signalName = "" spy.target = target spy.signalName = signalName
}
function test_flickUbuntuTestCase() { setupSignalSpy(signalSpy, freshFlickable, "movingChanged") flick(freshFlickable, 50, 50, -units.gu(10), -units.gu(10)) signalSpy.wait() compare(signalSpy.count, 1, "No movingChanged signal after simulating a flick.")
}
}
}
revision 1864
System setup: Vivid + Overlay PPA (i.e. same as phones/tablets)
libqt5qml5: ~overlay3 2ubuntu11~ vivid4
Installed: 5.4.1-1ubuntu11
libqt5core5a:
Installed: 5.4.1+dfsg-
UbuntuTestCase provides a flick() function whose main purpose is to produce a flick event when executed on Flickable.
I noticed that this does not always happen, causing flakiness of some of the UITK tests (in my case, it's the Scrollbar/ ScrollView tests I'm working on)
Here is a test case that reproduces the issue, once every 10-200 runs, depending on the configuration (I use a simple script to run it until it fails)
Please note that uncommenting the debug lines such as onMovingChanged onFlickingChanged will make it harder to reproduce the bug.
Enabling QT_LOGGING_ RULES=" qt.quick. mouse.debug= true" or onContentYChanged will make it even harder.
Since I already went through the effort, I'm posting here the debug log coming from the failed and successful runs: pastebin. ubuntu. com/15186789/ Note how "flicking" never becomes true pastebin. ubuntu. com/15186784/
- Typical failed run ---> http://
- Typical successful run ---> http://
Here's the code I used to reproduce the bug:
import QtQuick 2.4 Components. Styles 1.3
import QtTest 1.0
import Ubuntu.Test 1.0
import Ubuntu.Components 1.3
import Ubuntu.
import QtQml.Models 2.1
Item {
id: main
width: units.gu(50)
height: units.gu(100)
SignalSpy {
id: signalSpy
}
SignalSpy {
id: anotherSignalSpy
}
Item {
anchors. fill: parent
property alias flickable: freshFlickable
Flickable {
anchors. fill: parent
contentHeight : content.height
contentWidth: content.width
clip: true
//onContentYC hanged: console. log(contentY)
//onMovingCha nged: console. log("MOVING" , moving)
//onFlickingC hanged: console. log("FLICKING" , flicking)
Rectangle {
id: content
width: units.gu(40)
height: units.gu(200)
color: "blue"
Item {
width: units.gu(20)
height: units.gu(30)
id: freshFlickable
}
}
}
}
UbuntuTestCase {
name: "FlickBug"
when: windowShown
function setupSignalSpy(spy, target, signalName) {
spy. clear()
spy. signalName = ""
spy. target = target
spy. signalName = signalName
//reset signalName otherwise it will look for the old signalName in the new target
}
function test_flickUbunt uTestCase( ) {
setupSigna lSpy(signalSpy, freshFlickable, "movingChanged")
flick( freshFlickable, 50, 50, -units.gu(10), -units.gu(10))
signalSpy. wait()
compare( signalSpy. count, 1, "No movingChanged signal after simulating a flick.")
}
}
}