KFilePlacesModelTest

[David Faure]

On Wednesday 08 July 2015 07:58:22 Kevin Ottens wrote:
> 
> On Saturday 04 July 2015 22:24:50 David Faure wrote:
> > CI says:
> > 
> > 10:59:57 QDEBUG : KFilePlacesModelTest::testReparse() Expected:
> > ("/home/jenkins", "remote:/", "/", "trash:/", "/media/nfs", "/foreign",
> > "/media/XO-Y4", "/media/floppy0", "/media/cdrom", "/foo") 10:59:57 QDEBUG :
> > KFilePlacesModelTest::testReparse() Got: ("/home/jenkins", "remote:/", "/",
> > "trash:/", "/media/floppy0", "/media/cdrom", "/media/nfs", "/media/XO-Y4",
> > "/foreign", "/foo") 10:59:57 FAIL!  : KFilePlacesModelTest::testReparse()
> > Compared lists differ at index 4. 10:59:57    Actual   (placesUrls()):
> > "/media/floppy0"
> > 10:59:57    Expected (urls): "/media/nfs"
> > 10:59:57    Loc:
> > [/home/jenkins/builds/kio/kf5-qt5/autotests/kfileplacesmodeltest.cpp(186)]
> > 
> > Anyone knows how the ordering is supposed to work in that unittest?
> > 
> > I see that Kévin's commit 25941ce2633d7ec710142c4c5f26e93369a09786 was
> > already about ordering...
> 
> Yes, the fact that KFilePlacesModel uses QSet internally doesn't make that 
> very reliable, that's what my latest commit was about. I guess since then the 
> internal behavior might have changed? Maybe we should switch to an ordered 
> QVector instead of the QSet?

One year later, this test has regressed again.
Despite qputenv("QT_HASH_SEED", "0") and qputenv("QT_NO_CPU_FEATURE", "sse4.2"),
the ordering changed again, I have no idea why (Giuseppe or Volker, any idea?)

https://build.kde.org/view/Frameworks%20kf5-qt5/job/kio%20master%20kf5-qt5/51/PLATFORM=Linux,compiler=gcc/testReport/junit/%28root%29/TestSuite/kiofilewidgets_kfileplacesmodeltest/

The thing I wonder is... does it really make sense to have a model with random ordering?
Isn't it a problem for users if their visible list of places is different between every run?
Or am I missing something and the different order in the test isn't actually user visible?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160507/2aeda16b/attachment.sig>