There's a good idea, however, I am not sure that the datafile loading mechanism is exposed to python & scheme.
If you analyze test-transaction.scm and test-commodity-utils.scm you'll see how each test will generate an in-memory datafile with customized data designed to test aspects of transaction.scm and commodity-utilities.scm. So far this is the best way I found to test individual components. I'm sure python could receive similar tests. You're welcome to take up the reins! On Tue, 4 Dec 2018 at 19:54, <c.holterm...@gmx.de> wrote: > Hello all, > > just reading this. When I started to look into the unit tests for > python I wondered if there was some test data to read. I thought > it would make more sense to first test reading and then test writing. > > I wonderes if there was some example date that the c as well as > the bindings could be tested on. I think that would be useful. > > Generating and checking such file acts like a test for the whole > system. > > regards, > > Christoph > > > Am 11.11.18 um 12:54 schrieb Sébastien de Menten: > > Hello Chris, > > > > I am definitely interested into such gnucash data set of > > books/accounts/etc > > for testing piecash (reports, performance,.. ). With the transition to > > gnucash 3 coming to maturity, I planned to convert/rework the existing > > set > > of sample books ( > > https://github.com/sdementen/piecash/tree/master/gnucash_books) so if > > you > > have something that may be useful in this respect... > > Did you already share something on GitHub? > > > > Sebastien > > > > On Sun, Nov 11, 2018, 03:05 David Cousens <davidcous...@bigpond.com > > wrote: > > > >> Chris Millsap, Chris Good > >> > >> There is some limited test and example data in the GnuCash sources > >> .../gnucash-src/doc/examples. Not very extensive. These days a lot of > >> testing effort is shifted towards unit tests rather than extensive > >> overall > >> functional tests although they still have a place. I would think there > >> would > >> be a serious problem in validation of a data set and then the > >> maintenance > >> issues you alluded to. Another difficulty would be defining a test > >> data set > >> which would cover the various feature sets adequately, e.g. business, > >> trading, multicurrency etc. To define an adequate test data suite > >> would > >> also > >> require an extensive knowledge of the code base in any case. > >> > >> Possible but is it really worth the effort? In accounting if major > >> features > >> like compliance with the accounting equation, zero sum for transaction > >> splits are broken, then it will be generally obvious very quickly and > >> the > >> unit tests on the engine seem likely pick that up. > >> > >> What is it that you would wan't a test data suite to do that is not > >> covered > >> by the existing unit tests? > >> > >> David Cousens > >> > >> > >> > >> ----- > >> David Cousens > >> -- > >> Sent from: > >> http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html > >> _______________________________________________ > >> gnucash-devel mailing list > >> gnucash-devel@gnucash.org > >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > >> > > _______________________________________________ > > gnucash-devel mailing list > > gnucash-devel@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
