Zitat von John Ralls <jra...@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
