[GSOC] Data model unit testing

[Muslim Chochlov]

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, time to test one condition
(branch) takes me about 10 minutes. All above brings me to (4.2875 * 866 *
10)/(60*8) = 77.35 working days. Now google allocates 3 months of coding
that is 66 working days (being realistic :). 77 and 66 don't match at all.
What I propose is to change the goal to "cover at least 80% of the libqof
module". Then we get (4.2875 * (866 * 0.8) * 10)/(60*8) = 61.88 working
days. In the worst case this will still provide a pretty cool code coverage
(as 80% is considered a standard in SW engineering) and I will be able to
finish my project in time. In the best case the 100% coverage will be done.
Let me know if such goal modification is ok with you guys. In that case I'll
have all the requirements gathered from you and submit the project.

Saluti,

M.Chochlov

On Thu, Mar 31, 2011 at 10:20 AM, Christian Stimming <stimming at tuhh.de>wrote:

> Zitat von John Ralls <jralls at ceridwen.us>:
>
>> I came up with some assessments regarding the project.
>>> More in detail:
>>> - Different measurement tools calculate about 16-17k lines of code in
>>> libqof module.
>>> - Number of unique functions is ~800 and ~ 500 of them are public, that
>>> is available to other packages.
>>>
>>
>> Your assessment is fine. If getting LibQof fully tested is what you think
>> you can get done in the scope of GSoC, then that's the right target. After
>> all, at this point you're the only one here who knows how fast you can work,
>> and frankly you're probably understimating the complexity. While a lot of
>> those functions are simple setters and getters, there are also functions
>> that are over 100 lines long and will need many tests run many times to
>> fully exercise the different paths. Some of those will need to be refactored
>> in order to get at the intermediate results for good testing. There are also
>> interfaces (e.g., Backend) which will need mocks to exercise the paths in
>> the interfaced code, and I expect that you'll want to mock parts of Qof
>> itself while testing other parts to keep complexity under control. It's
>> plenty of work to get done in ~90 days.
>>
>
> I completely agree with John here.
>
> Additionally, I would like to point out that some of the libqof functions
> might turn out to be unused throughout gnucash. If you or we encounter any
> of those functions, we can disable them immediately and not spend any
> further unittesting effort on them. The initial design of the "libqof"
> module by Neil Williams had the intention of using that code as a library
> from several independent projects. From that time, several functions might
> still exist which were never useful for gnucash and are subsequently unused.
> The best decision about those functions is to throw them out immediately
> such as here http://svn.gnucash.org/trac/changeset/20402 because if
> they're unused, they are also untested for a very long time and have a high
> probability of being wrong in the first place. Just throw them out.
>
>
>  I'm making good progress on the Gir2Umi program, so I hope to have a
>> skeleton UML model in another week or so. Once we have that we can assess
>> how much hand-modelling we need to do.
>>
>> There's no real priority within LibQof. It's at the middle of Gnucash and
>> in the way of some important changes that we need to make, and we need to be
>> sure that we don't break anything when we make those changes. That's what
>> the tests are for. It seems to me that that should make a pretty clear goal
>> for your application, too.
>>
>
> Indeed. Thanks for the UML modelling work - I'm curious how this is going
> to look like when it's ready :-)
>
> Regards,
>
> Christian
>
>