[GSOC] Data model unit testing

[John Ralls]

On Apr 1, 2011, at 9:37 AM, Muslim Chochlov wrote:

> 
> On Fri, Apr 1, 2011 at 9:12 AM, Christian Stimming <stimming at tuhh.de> wrote:
> Zitat von John Ralls <jralls at ceridwen.us>:
> I estimate the effort in the following way:
> 
> (AVG_of_branching * number_of_functions * time_to_test_one_branch_in_minutes)/(minutes_in_hour * number_of_working_days).
> Avg of branching in function is something that i get by dividing code complexity number (3729) by number of functions, (...)
> 
> Like I said, you're the only one at this point who knows how fast you can code. But your calculations are a bit, um, overly precise.
> 
> I agree with John on the "overly precise" bit. However, I don't think this is a problem at this point in time at all.
>  
> Couldn't agree more. Measurements in software engineering become kind of speculative when it comes to time/effort estimation. But still it's the only way to at least try to see the "big picture".
> John, I'm using C and C++ Code Counter to evaluate complexity. And I guess it performs some very similar calculations to those you did, because the numbers we get are very close 3600 and 3729. The difference is in hours per week, I count it as 40 hours/week :)
> 
> For your project we can simply confirm that the goal of "full unittest coverage of all of libqof" is too ambitious for GSoC. Doing the complexity estimations is one out of several useful ways to tell up front whether the task can or cannot be done, and it is also a valid part of such a GSoC project. Thanks for the numbers :-)
> 
> I agree with John that you should pick a useful subset of libqof, and this way, the project will surely fit inside GSoC again.
> 
> As for how to find the "useful subset": I've created a list of libqof's symbols which are used from the rest of gnucash (attached) with usage count. This list of used symbols has 346 entries, whereas the list of libqof's exported symbols contains 524 entries. This is already a strong indication that libqof might contains 524-352=172 functions which are unused throughout gnucash. Following my remarks in my last message I'd say almost all of those 176 unused functions should be removed anyway, which means your project size might already reduce into useful ranges.
> 
> Note: I've done this for *symbols*. A symbol corresponds to an exported function. The libqof code might provide more functions to the rest of gnucash which are still used but are not a symbol. For example, all macros and all enums are provided to the rest of gnucash but are not symbols. Similar for inline functions even though I don't know whether we actually use those. The details for my research is shown below.
> 
> For now, I'd propose you should go ahead in writing up your application, and we can just confirm we will find a useful subset of libqof to be covered that will be doable within GSoC.
> 
> Let me get it right, will you provide me with the subset before the application deadline (April 8)? Or I continue to research by myself and come up with more or less precise estimations. I already submitted the draft of proposal today. It's almost complete, except for assessment part. You should be able to check it out through gsoc application.
> 
>  
> Regards,
> 
> Christian
> 
> 
> # Create list of symbols exported from libqof in file "exportedsymbols"
> nm -A src/libqof/qof/.libs/libgnc-qof.so  | grep ' T ' > exportedsymbols
> 
> # Find all non-libqof binaries of gnucash
> L=`find . -name '*.so' | grep -v libgnc-qof`
> L="$L src/bin/.libs/gnucash"
> 
> # For each other binary, lookup the imported (unresolved) symbols, grep those
> # that are from libqof, then sort the resulting list and count by occurrence
> for A in $L ; do   nm $A | grep ' U ' |   sed 's/^.* \([^ ]*\)$/\1/' | grep -wFf- exportedsymbols |   cut -d: -f2 ; done | sort | uniq -c | sort -nr > all-qof-usage
> 
>  
> One more thing. Don't know if I have to inform you that I was able to build application from source and run it. But anyway I did it :)
> And big thanks to you guys for comprehensive and fast feedback you provide. You are being more than helpful!

Muslim,

I was teasing about the hours. 

As promised, I looked over the headers in Qof this morning. I started with  Christian's suggestion of using the number of external calls into a header's published functions*. 

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. 

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.

QofBackend (10) is an interface that is tested adequately for now; its users are in src/backend. 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.

Christian, you're more familiar with a lot of this code than I am. What do you think of the list?

Regards,
John Ralls

* grep -rl --include=*.[ch] qof_foo src | grep -v libqof/qof | wc -l where qof_foo is the function prefix for the class (or "class" in some cases) in question. A few items needed slightly different REs; for example for qof_util I used 'qof_.*_edit' to capture the qof_begin_edit, qof_commit_edit, and qof_rollback_edit calls.