TR unit tests

[christopherlam]

Work in progress. Divided renderer into multistage, will now write tests.

[christopherlam]

So far the unit tests are rather simplistic and tests mainly simple filtering and display elements. Genuine testing of sortorders, currency conversions etc is far more difficult and requires html parsing :-(

[jralls]

Could you be a bit more expressive with the commit messages?

[christopherlam]

Could you be a bit more expressive with the commit messages?

Hmm I'm still trying to find the right toolchain, and I've rebase/fixup for now. Unfortunately travis-ci guile uses guile-2.0.9 whch doesn't have srfi-64 :(

[christopherlam]

For travis to pass I may have to forego srfi-64 and write custom macros instead, which are not that difficult.

[jralls]

I'm not sure what Travis's limitations have to do with cryptic commit messages, but if the purpose of the PR is to run Travis on work that isn't actually ready to merge, there are a few alternatives that might work a bit better:

• You can turn on Travis for your own Github repository.
• You can set up docker and run the tests in the same docker environments that Travis uses, but on your own machine
• You can set up some other sort of VM (VirtualBox is popular for Linux) with OS images that match the Travis setup. This might be the best solution for your purpose because it allows full interaction with the VM without having to set up VNC connections by hand.

[christopherlam]

Wish to canvas opinion about a hack to add srfi-64 in travis -- I've copied srfi-64 into common/test-core/ and modified commonbuild to check for srfi-64, and copy it if does not exist (ie guile-2.0.9 or earlier). This passes on travis. It'll be a shame to seek another unit-test toolchain when srfi-64 is very well designed. Will this hack be acceptable? See latest commit on https://github.com/christopherlam/gnucash/commits/TR-unittest

[christopherlam]

Code that's lifted from somewhere else goes into "borrowed".
But I think it would be simpler and better to test for SRFI-64 in the root CMakeLists.txt and enable your unit tests only if it's available. Geert, what's your opinion?

Whoops. Rebasing meant the 6a173f6 commit including comment was lost. I've moved to ./borrowed in my tree. I was fighting with travis all day until this worked. SRFI-64, SXML and SXPATH is a good combination for stress testing reports. With this I can be much more productive.

[gjanssens]

I would definitely prefer testing for SRFI-64 in the root CMakeLists.txt and only enable scheme unit testing when it's available.
Note also the way you added your test in cicommon in the 6a173f6 is not very portable. It will fail on a system which only has guile 2.2 installed. You could add an extra test for guile 2.2 but it quickly gets confusing. And it would break again when guile releases 2.4.
Better would be to run guile -c '(use-modules (srfi srfi-64))' and check whether that fails or not.

[christopherlam]

I would definitely prefer testing for SRFI-64 in the root CMakeLists.txt and only enable scheme unit testing when it's available.

Ok - this would mean travis-arch has guile-2.2 can run the tests and travis-ubuntu with guile-2.0.9 will skip them. A local build with guile 2.0.10 onwards will run the tests successfully.

Note also the way you added your test in cicommon in the 6a173f6 is not very portable. It will fail on a system which only has guile 2.2 installed. You could add an extra test for guile 2.2 but it quickly gets confusing. And it would break again when guile releases 2.4.
Better would be to run guile -c '(use-modules (srfi srfi-64))' and check whether that fails or not.

The reasoning was, given guile>=2.0.10 always has srfi-64, we'd only need to test that the /usr/share/guile/2.0/ path exists and doesn't contain srfi-64. guile-2.2 onwards would skip the whole 'if' section.

Alternatively the following?

 if ! guile -c '(use-modules (srfi srfi-64))'; then
    # copy srfi into /usr/share/guile/2.0/ <-- still hardcoded to guile-2.0
 fi

[christopherlam]

PS it's still preferable to disable tests for travis-ubuntu then please let me know how CMakeLists.txt should change!

[jralls]

Run the test Geert proposed above and set a variable HAVE_SRFI64 based on the results. Then in the various test/CMakeLists.txt call add_scheme_test for srfi64 based tests only if HAVE_SRFI64 is true.

[christopherlam]

Ok - the following does the trick - will enable HAVE_SRFI tests if guile >= 2.0.10 - the downside is an ugly error message during build script. Alternatively I could also add to guile22 section to quietly enable HAVE_SRFI64.

# Test that guile has SRFI-64. This is required for some unit tests.
EXECUTE_PROCESS( COMMAND ${GUILE_EXECUTABLE} -c "(use-modules (srfi srfi-64))"
  RESULT_VARIABLE GNC_SRFI64_RESULT
)

 IF (GNC_SRFI64_RESULT EQUAL 0)
  MESSAGE(STATUS "Using guile SRFI-64")
  SET(HAVE_SRFI64 TRUE)
ENDIF()

[jralls]

You can probably eat the error message with

EXECUTE_PROCESS( COMMAND ${GUILE_EXECUTABLE} -c "(use-modules (srfi srfi-64))" > /dev/null 27>1

[gjanssens]

Or more the cmake way by adding "ERROR_QUIET" to the execute_process invocation. Optionally, it may also need "OUTPUT QUIET" if guile is not writing to stderr.

And please write cmake commands in lowercase. I know most of it is upper case, but I want to fix this for 4.0. By writing lowercase now for new cmake functionality, there's less to change in the next dev cycle.

[gjanssens]

Hmm, looks like you figured out the "ERROR_QUIET" option already in PR286. Only the lowercase request remains then.