On Saturday 07 May 2016 19:50:36 Michael Pyne wrote: > On Sat, May 7, 2016 14:33:53 David Faure wrote: > > 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? > > Is it trying to test that the entries are present in a *specific* order, or > simply that the entries will be maintained in a constant order between > serialization/deserialization? If it's the latter then we could instead use > whatever the existing order is in one call as the expected order for the > second call. > > Also, if we're just trying to show that a specific set of entries would be > present, couldn't we sort the expected and the actual lists before doing the > comparison, to make it independent of order? In other words we could break > the > test into two: 1) ensure order is properly saved and loaded, and 2) ensure > right items are present independent of their order.
For the record, this is now fixed in solid and kio. The random ordering came from QList->QSet->QList, which I managed to simplify to avoid the QSet step. Giuseppe: it wasn't about two sets, but about a single intermediary qset, and then checking the final QList with a fixed "expected" list. Since everything is fixed upfront (the initial QList comes from parsing a test file), it looked like this could be made reliable - but somehow on two different machines with the exact same code (AFAICS), I was getting a different order. Oh well, doesn't matter anymore :-) Thanks for the input everyone. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
