Hello,
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? > but I think the new CI machine is what triggered the above failure. That's surprising, it's supposed to be somewhat insulated from the underlying system (uses solid fake backend for that). > Locally this test method passes, but the test fails further on, also about > ordering: Not really surprising, unfortunately, the tests couldn't be properly insulated from each other at the time (maybe nowadays it'd be possible) so if one derails it's likely that all the following ones will fail. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
