User:Christopherlam

Project 2 Creating test-transaction.scm

I will document some thoughts about development of implementation/mock testing for transaction.scm. Without a framework, creating test-transaction.scm is an awkward hierarchy of function calls as follows:

(and (test-1) (test-2) (test-3))

I have tried yawaramin's ggspec and guile-2.0's SRFI-64 and I think the latter is a much simpler tool. I've created test-transaction.scm based on it, and is still in progress.

A common issue is to determine test coverage. Fortunately scheme has an inbuilt coverage report generator. Here's relevant excerpt from test-test-transactions.scm to illustrate.

(use-modules (system vm coverage)
             (system vm vm))

;; coverage requires a VM
(define %test-vm (make-vm))

;; we need to add location of transaction.scm otherwise it's not included in report
(add-to-load-path "/home/chris/sources/gnucash/gnucash/report/standard-reports")

(define (run-test)
  (test-runner-factory my-runner)
  (test-begin "transaction.scm")
  (null-test)

  ;; the following function generates the coverage report
  (call-with-values (lambda ()
                      (with-code-coverage %test-vm
                                          (lambda ()
                                            (null-test)
                                            (trep-tests)
                                            )))
    (lambda (data result)
      ;; and we save the result into /tmp/lcov.info
      (let ((port (open-output-file "/tmp/lcov.info")))
        (coverage-data->lcov data port)
        (close port))))
  (test-end "transaction.scm"))

The result of all this hard work is a coverage log.

We can download lcov from http://ltp.sourceforge.net/coverage/lcov.php

$ git clone https://github.com/linux-test-project/lcov.git
$ mkdir html
$ cd html
$ ../lcov/bin/genhtml /tmp/lcov.info

And the coverage log is converted to an html report.

Project 1 Completed Dec 2017

When I was offered opportunity to completely overhaul, I have sought to fix Transaction Report as much as possible, and add options to derive as much value as possible with the underlying data presentable as a customized TR.

This document will serve as useful summary for users, and also as a roadmap for rewriting the git history.

1. General thoughts

The original TR was a complete mess, grown and hacked together by years of accumulated crud. Many functions were created for single use, numerous lists of splits, options, and sortkeys being passed around for no particular reason. I have flattened the TR to a reasonable level; and I haven't quite finalized it yet. There are further flattening/abstracting refinements that can need to take place. e.g. the generic and versatile TR can be massaged to produce a report suitable for reconciliation, just by setting the right options. I can formalise it by creating another report initialized with the above options. I can also rewrite the Income GST Statement to also exist within transaction.scm (or ideally another file) that will just call the options-generator and the renderer with new values. These may require refactoring to allow modification of calculated-cells

2. Bugs were fixed

 a) bug for pre-1970 dates whereby the wrong weekday was selected
 b) bug for 'register-order sortkey being classed as a date-subtotal-type
 c) fixing debit/credit amount columns - sign reversal strategy was flawed
 d) fixing date sorting to understand periodic sorting, rather than strict daily sorting

3. Additional features were added

 a) proper debit/credit subtotals in the appropriate columns
 b) multicolumn values and subtotals
 c) friendly headers for debit/credit
 d) optionally render Account Description in the subheading
 e) add 'daily subtotal strategy - useful for "daily report" types
 f) optionally hide the transactional data - but only a subtotals are enabled
 g) new filters - transaction/account substring/regex filters, reconciled-status
 h) new sortkey - reconciled status unreconciled->cleared->reconciled with subtotals
 i) new infobox - summarise options used and optionally render at the top of report
 j) sign reversal strategy - will default to follow the global pref
 k) optionally indent left columns according to grouping strategy

4. Unsure how to fix

 a) debit/credit signs are wrong if the sortkeys are 'other-account types