It passes only by pure chance as NotepadPart uses QFile, which understands such an url. So the value of that new autptest is questionable, as this is not testing any API promise.

For ReadOnlyPart::localFilePath() it says: "Returns the local file path associated with this part. " So a :/ resource url is rather out of scope, at least by traditional meaning of "local file path". Any KParts plugins which pass the file path on to non-QFile-using code will fall flat on such qrc path.

Right, this would fail if the part was not using QFile, indeed. Still, at the level of the KParts frameworks itself it's all fine ;)

In D12477#403709, @dfaure wrote:

Still, at the level of the KParts frameworks itself it's all fine ;)

Which "level" do you mean here? This test only works by pure chance given the current implementation detail of NotepadPart. It is not testing something part of the API contract,

Especially given the commit message "I wasn't sure if :/foo stuff would work, so I tried writing a unit test to help me.". It only works with KParts plugin implementations which use QFile. This test here sends the wrong signal IMHO, and only tests a random behaviour due to the way the NotepadPart is implemented.