Merge lp://qastaging/~aacid/dee-qt/more_tests into lp://qastaging/dee-qt

Question, do we want to leave the append/remove functions in DeeListModel or move them to TestDeeListModel since we only use it for the QML tests?

PASSED: Continuous integration, rev:86
http://jenkins.qa.ubuntu.com/job/dee-qt-ci/16/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/dee-qt-trusty-amd64-ci/4
    SUCCESS: http://jenkins.qa.ubuntu.com/job/dee-qt-trusty-armhf-ci/4

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/dee-qt-ci/16/rebuild

> Question, do we want to leave the append/remove functions in DeeListModel or
> move them to TestDeeListModel since we only use it for the QML tests?

Definitely not for the public DeeListModel, if we want to turn the wrapper into a read-write model, there should be a good reason (not just add some tests).

What are the actual coverage numbers for before and after?

> > Question, do we want to leave the append/remove functions in DeeListModel or
> > move them to TestDeeListModel since we only use it for the QML tests?
>
> Definitely not for the public DeeListModel, if we want to turn the wrapper
> into a read-write model, there should be a good reason (not just add some
> tests).

Done

41 - m_parent->beginResetModel();
42 m_count = dee_model_get_n_rows(m_deeModel);
43 - m_parent->endResetModel();
44 Q_EMIT m_parent->countChanged();
45 }
46 else
47 @@ -156,6 +155,7 @@
48 g_signal_connect(m_deeModel, "notify::synchronized", G_CALLBACK(onSynchronizedChanged), m_parent);
49 m_listeningSynchronized = true;
50 }
51 + m_parent->endResetModel();

One observation: with that change we emit countChanged inside beginResetModel() -- endResetModel(), however if the backend dee model is not synchronized yet, we emit countChanged in onSynchronizedChanged() and it's outside of beginResetModel() -- endResetModel() there. I'm not sure if this is can have any side effects (probably not), but just mentioning it; perhaps it makes sense to make it consistent?