Hi, 2011/4/2 Christian Stimming <stimm...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
