Isn't it better to move the last QCOMPARE(count,count); up first? Or is it to be able to easier debug if something went wrong?

And use what instead? maybe mark deprecated?

actions is const, so range based for is free to use

this is the only place the QList is actualyl modified so it is actually safe. but only until the next person modifies the code...

Not exactly. QList's [i] asserts when called out of bounds. It didn't happen before, because when the test passes, actions == expectedActions ;)
It simply happened to me while working on the unittest and getting less actions than expected.

Right it's at the end because when "A,B,C" is matched against "A,D,B,C" I'd rather be told "at position 1 I expected D but got B" than "expected 3, got 4". Easier to debug.

It was, but ok, let's remove it.

And use nothing, it was only used internally and it's not used anymore.

AFAICS nobody uses this, but yes, good idea to add deprecation macro to make sure it stays that way.

I actually looked at the kdelibs3 code and it was using QValueList already ;)

Yes it's dangerous to store iterators into a QList or QVector, however what this code does (right under this comment) is to recalculate these two iterators when adding to the QList, which solves exactly that risk. My commit simply makes that more explicit in the comment.

Hmm, I forgot to check for code _removing_ from the list. Although I doubt QList reallocates when shrinking. Checked now, there isn't.

BTW I also searched bugzilla for crashes related to ContainerNode and BuildHelper and didn't find anything ;)