[GSOC] Data model unit testing

Muslim Chochlov muslim.chochlov at gmail.com
Wed Apr 6 18:00:24 EDT 2011


Hi,

2011/4/2 Christian Stimming <stimming at tuhh.de>

> Am Freitag, 1. April 2011 schrieb John Ralls:
> > I found the most heavily used to be QofObject, Guid, and gnc-numeric with
> > 197, 197, and 174 external references respectively. However, the latter
> > two are straightforward data manipulation libraries (which probably
> belong
> > in core-utils anyway, as does gnc-date (42)) and testing will be pretty
> > simple. I think you can ignore them.
> >
> > QofObject is an interface description which is widely used and needs to
> be
> > very thoroughly tested. Next on the list is QofInstance (105), the only
> > direct GObject subclass and the base class for 14 engine classes. It has
> a
> > helper class, QofId (34) which will probably need to be tested in concert
> > with it. qof_util.c (22) implements some important transactional
> functions
> > which we need to ensure work perfectly and then use widely.
> >
> > QofSession (48) is very important and has some of the most convoluted
> code.
> > it shares with QofBook (72) the organization of the objects upon which
> > Gnucash operates. They have a major helper class KVP_Frame (71) which
> > isn't in any object framework AFAICT, it's just normal functional C. It's
> > one of our major problem areas with the sql backend and has no test
> > coverage.
>
> I agree that the following list should be the highest priority for
> unittesting:
> - QofObject
> - QofInstance
> - QofSession
> - QofBook
> - kvp_frame


Then if it is ok with you, I'll consider covering the entities above with
unit tests as a final goal. There is almost three times less branching in
them, than in the whole libqof module (~1200) so I'll be able to dedicate 3
times more effort to test each case (2tests/hour).  And I guess that would
be more than realistic approach :)
If you confirm I'll make final tweaks to my proposal today or tomorrow and
hope for the best :)



>  > QofQuery (50), QofEvent (43), and QofClass (30) form another work group
> > which is supposed to abstract data retrieval. I haven't yet worked out
> > whether it's a useful abstraction, though, so perhaps it can be lower
> > priority.
>
> Right, those would be lower priority. The QofQuery code might need
> modification and unittesting once we try to go into the multi-user backend
> direction, but that is not yet the case.
>
> > QofBackend (10) is an interface that is tested adequately for now; its
> > users are in src/backend.
>
> Agreed.
>
> > QofLog (9) is mostly a wrapper around the g_log
> > functions from GLib. It's not worth any testing effort.
> >
> > Groups with no outside users are QofGobject, QofSql, QofSerialize, and
> > QofDeserialize. Those with very few and which I haven't looked at in
> > detail are QofReference (1), QofChoice (6), and Md5.
>
> All those latter ones are probably strong candidates to be removed (and
> QofLog
> replaced by pure g_log usage). Maybe I'll just start removing those where
> it
> can easily be confirmed that no-one uses them inside gnucash. But that's
> surely not Muslim's task here.
>
> Regards,
>
> Christian
>

Saluti,

M.Chochlov


More information about the gnucash-devel mailing list