On Jan 10, 2011, at 5:17 PM, Derek Atkins wrote: > John, > > On Mon, January 10, 2011 7:04 pm, John Ralls wrote: >> I've written a fairly extensive change to manage database version changes, >> and I'd like to add unit tests for the new functions before I commit it. >> Longer-term, of course, I'd like to have full unit test coverage of the >> non-gui parts of Gnucash before we start on the major surgery we've been >> discussing the last couple of weeks. >> >> The issue is what framework to use? GLib from 2.16 (supported by >> everything stable except RHEL 5 and its derivatives, so I don't feel any >> remorse about using it in 2.4 before we branch it) provides a serviceable, >> though primitive, framework that we can introduce without adding a >> dependency, and it integrates nicely with automake. It would, however, >> increase our dependency on GLib and it lacks the automatic registration of >> test cases and suites afforded by more sophisticated frameworks. >> >> Any comments? > > My feeling is that so long as it doesn't add new dependencies and ties > into "make check" then you can do whatever you want. > > We already have some code to generate random GnuCash data; tie that into > whatever 'check' system you want to perform functional tests, and make it > work with "make check".
Glib it is, then. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
