Reports: Utilization of urls

Geert Janssens geert.gnucash at kobaltwit.be
Sun Mar 13 14:15:59 EDT 2016


On Sunday 13 March 2016 18:49:33 Carsten Rinke wrote:
> "several of your patches I did review and commit only to revert them
> afterwards again"
> I think that references the
> - cashflow calculation issue, which the patch was later-on declared
> "obsolete - not a bug, but misunderstanding of function"
> - the overlapping x-axis label issue, that showed problems on other
> distributions, which I could not see in my environment
> 
Those in addition to commits unrelated to your work I did myself at some point and had to 
revert... :(

> "unit test set available for most of our guile modules"
> Even though I very much support this idea: I don't think that this
> would have avoided the problems above, especially as it is not
> feasible for me to run a mutli-distro environment.

The overlapping x-axis regression was reported in
https://bugzilla.gnome.org/show_bug.cgi?id=737815

There is no mention of it being platform specific. On the contrary it was reported on several 
platforms, being Windows, OS X and several flavors of linux.

I don't expect you to run a multi-distro environment and there's no need to.

Having said that, you are probably right that this particular issue would not have been caught 
with unit tests, because it only had visual repercussions resulting from a bug on jqplot or 
wrong use of that library. There was no data to match against.

> For me the question is, if there is man-power available to qualify and
> verify the solutions and patches before they are committed, best
> case: in different environments.
> My perception is that currently this all falls back onto only your
> table. Is my perception correct?

I do most of the reviews of scheme code indeed, although John does so as well from time to 
time. That gives us 2 platforms already if you like (OS X and Fedora linux).

> 
> Independent of that:
> What do you have in mind with a "unit test set"?

Unit tests are there to verify that isolated functions return expected results on given input. So a 
"unit test" set would be a series of tests that do this for all functions written in guile. That's the 
theory. We won't be able to do that for *all* guile code, but we could do so for many.

> You mean documentation as kind of work instructions for testing?
> Or do you mean an automated test framework?

I mean a set of test routines that are called whenever you run 
make check
on our source tree.
There are already a couple in place, like for example in
src/report/standard-reports/test
But our test coverage a (far) from complete.

Regards,

Geert


More information about the gnucash-devel mailing list