[GSOC] Data model unit testing

[Muslim Chochlov]

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!

Saluti,

M.Chochlov