Should be, via qof_session_begin() and qof_session_load().
It is indeed better for *unit tests* to use data tailored to the *function*
under test. But unit tests should be in the same language as the code that
their testing. Bindings should do broader integration tests, relying on the
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
Christoph,
Yes, there are test XML files in libgnucash/backend/test/xml2 and
libgnucash/backend/sql/test. I don’t think that any of them are comprehensive,
but they’re a pretty good start.
Regards,
John Ralls
> On Dec 4, 2018, at 8:50 PM, c.holterm...@gmx.de wrote:
>
> Hello all,
>
> just
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
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 (
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
Hi Chris (Millsap),
My initial thoughts are that this would quickly become obsolete and developers
would usually already have easy access to their own large data files, so would
probably not be worth much effort.
I'm not a Gnucash developer though and they probably have other ideas, so I've
