On 31-01-13 19:04, John Ralls wrote:
How can we in the future improve our process to something in which the
history clearly reflects what actually happened, in which no work is
lost (by forgetting to backport) and without too much overhead.
And also test/review changes before they go into the release branch?
The generally accepted best practice for that is to require 100% test coverage
and to require that all tests (including a new one that covers the current
change) pass. It doesn't seem likely that we would adopt that practice.
No, we're not set up for that. But I believe it should be one of our goals to
get better test coverage. I know you have this on your agenda and I'm quite
happy about it.
A couple of times I started looking into writing tests myself, but never
managed to actually produce some due to lack of time and experience. Perhaps
this is a good time to ask:
a. do you know of a good introduction to unit testing ?
b. is there some documentation on the unit testing framework used in gnucash ?
How should a test be constructed ? Are there particular functions that should
be used ? Things like that.
We have a wiki page [2] on the subject, but it's a bit light. I'll work on that
a bit. Perhaps you (and others) could look it over and suggest more topics that
it needs to cover.
Regards,
John Ralls
[1] http://wiki.gnucash.org/wiki/Development_Process#Changeset_Auditing_Process
[2] http://wiki.gnucash.org/wiki/Testing
The wiki page is already a good starting point. Thanks. For some reason
I hadn't found it before (probably didn't look hard enough).
Any reason you have decided to the unstable documentation of the GLib
testing framework ?
Geert
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
