Reports: Utilization of urls
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
> "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
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
on our source tree.
There are already a couple in place, like for example in
But our test coverage a (far) from complete.
More information about the gnucash-devel