[GSOC] Data model unit testing

[Christian Stimming]

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