Add Automated Testing

[cakarsubasi]

A consistent, reliable way of testing and benchmarking GEL would be beneficial for my project (and GEL as well).

A short list of changes:

• The Github workflow is set to run on [push], it should be set to run on [push, pull_request]. The workflow already calls ctest meaning no other changes are needed.

• Add include(ctest) to the top level CMakeLists.txt to enable testing.

• Include all of the test projects in the top CMakeLists.txt and set their binaries as tests. Edit the test project CMakeLists.txt files so they can be run both ways. (I have also noticed that the project names and the find_library commands were incorrect in a number of these projects).

• Update documentation to reflect the changes.

I have already begun working on these changes and can create a PR fairly quickly.

Other Potential Changes:

These changes are not immediately relevant to the task at hand and are more disruptive, but may help long term maintainability.

• Move test and demo directories outside of src. This is the more common way to structure C++ projects.
• Get rid of the platform specific globbing in the main CMakeLists.txt and include the exact set of dependencies instead.
• Move headers to an include directory.

[janba]

I am grateful for these suggestions, and the shortlisted ones feel worthwhile. For starters, I implemented the suggestion to have the workflow run on pull_request. The idea of making the tests run by default is great. Unfortunately, the larger problem is that test coverage is poor. However, we have to start somewhere, so I think it is a good idea to do this, and I would be grateful for a PR!

Regarding the "Other potential changes". I think that I prefer keeping all source, including demo and test under "src". You are probably right that it is less conventional, but it feels relatively harmless. in the same vein, I also prefer having the header files with the source files. If someone installs GEL as a compiled C++ library (or a framework) there will be a bespoke header directory, but I feel that it is nice to have the files together during development. I am not sure what globbing is platform specific?

[cakarsubasi]

Disregard the platform specific comment, I seem to have mistaken it for something else while looking through so many different things. The CMake style manuals I have consulted[1] discourage the usage of globbing still, on the basis that changes in the build are not synchronized with the generated build files without re-running CMake. I don't think this is too serious of an issue though.

I have created #82 that modifies the build files to include some of the projects in src/test as tests, we can then work on further expanding the test coverage based on that template.

[1] https://cliutils.gitlab.io/modern-cmake/chapters/intro/dodonot.html

[cakarsubasi]

Although it is slightly hacky, it is also possible to extend testing to the Python files.

# Create a python environment in the build directory for testing
if (BUILD_TESTING)
    find_package(Python3 COMPONENTS Interpreter)
    # We need to pre-generate the venv, so we can avoid global installations
    execute_process(
        COMMAND "${Python3_EXECUTABLE}" -m venv .venv
    )
    # This is part of what the activate script does
    set(ENV{VIRTUAL_ENV} ${CMAKE_CURRENT_BINARY_DIR}/.venv)
    set(Python3_FIND_VIRTUALENV FIRST)
    unset(Python3_EXECUTABLE)
    # Make CMake find the correct executable
    find_package(Python3 COMPONENTS Interpreter Development)

    set(Python3_SITE_PACKAGES "${CMAKE_CURRENT_BINARY_DIR}/.venv/lib/python${Python3_VERSION_MAJOR}.${Python3_VERSION_MINOR}/site-packages")
    add_custom_command(
        OUTPUT "${Python3_SITE_PACKAGES}/pygel3d"
        COMMAND ${CMAKE_CURRENT_BINARY_DIR}/.venv/bin/pip install ${CMAKE_CURRENT_SOURCE_DIR}
        DEPENDS "$<TARGET_FILE:PyGEL>"
        COMMAND_EXPAND_LISTS
    )
    add_custom_target(PYGEL.test ALL
        DEPENDS "${Python3_SITE_PACKAGES}/pygel3d"
    )
endif()

A Python test can then be easily added like this:

add_test(NAME GEL.Test.PythonTest COMMAND ${Python3_EXECUTABLE} "${CMAKE_CURRENT_SOURCE_DIR}/python_test.py")

import pygel3d as gel
import unittest

class TestClass(unittest.TestCase):

    def test_succeed(self):
        print(gel.__all__)
        self.assertTrue(True)

if __name__ == '__main__':
    unittest.main()

I'm not too happy with this and I need to check if it is portable and works on the CI. In addition, the setup.py script is a problem since it copies the relevant .py files to the hardcoded build/ directory from their source location. It would be simpler to declare an inert custom CMake target that depends on the python files and setup.py and have the setup script run inside the build directory.