Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix and refactor tests #79

Closed

Conversation

flederwiesel
Copy link
Contributor

Fix test execution by complete refactoring.

Previously, the test scripts have been executed from a rewritten version, which
used sed to adjust binary paths. Not only have the tests passed despite the
scripts not being created correctly, this mechanism was also cumbersome and
intransparent.

This refactoring now uses the original test scripts from the source tree.

When building/testing with cmake/ctest, the (absolute) paths to executables
are being taken from the environment, which is set in CMake via the new
declare_test_executable() function.

When executing tests from make check (or for manual execution), the current
dir is used. Which is fine, if executed from the cmake build dir.

The path to the files containing the expected data is passed as parameter now.

Furthermore, some optimisations have been done in the bash scripts. Output files
of the test execution are not deleted anymore, which should be OK, if executed
in the build directory. EG_DATA is now also being passed as parameter.

Refactor and add contrib test also, although not clear how this is connected
and how this adds value to contrib...

Previously, the test scripts have been executed from a rewritten version, which
used `sed` to adjust binary paths. Not only have the tests passed despite the
scripts not being created correctly, this mechanism was also cumbersome and
intransparent.

This refactoring now uses the original test scripts from the source tree.

When building/testing with `cmake`/`ctest`, the (absolute) paths to executables
are being taken from the environment, which is set in CMake via the new
`declare_test_executable()` function.

When executing tests from `make check` (or for manual execution), the current
dir is used. Which is fine, if executed from the cmake build dir.

The path to the files containing the expected data is passed as parameter now.

Furthermore, some optimisations have been done in the bash scripts. Output files
of the test execution are not deleted anymore, which should be OK, if executed
in the build directory. EG_DATA is now also being passed as parameter.

Refactor and add contrib test also, although not clear how this is connected
and how this adds value to contrib...
Test `test1` has not been executed in CI, so I guess a change in the data set
just went unnoticed.
@flederwiesel flederwiesel changed the title Feature/fix and refactor tests Fix and refactor tests Dec 24, 2023
CMakeLists.txt Outdated Show resolved Hide resolved
@rouault
Copy link
Member

rouault commented Mar 3, 2024

@flederwiesel
make distcheck fails:

~/shapelib/build_ac$ LC_ALL=C make distcheck
make  dist-gzip dist-zip am__post_remove_distdir='@:'
make[1]: Entering directory '/home/even/shapelib/build_ac'
make  distdir-am
make[2]: Entering directory '/home/even/shapelib/build_ac'
make[2]: *** No rule to make target 'tests/stream1.out', needed by 'distdir-am'.  Stop.
make[2]: Leaving directory '/home/even/shapelib/build_ac'
make[1]: *** [Makefile:1247: distdir] Error 2
make[1]: Leaving directory '/home/even/shapelib/build_ac'
make: *** [Makefile:1348: dist] Error 2

@thbeu
Copy link
Contributor

thbeu commented Mar 6, 2024

There now is flederwiesel#1 to fix the distribution.

Note, that it was wrong anyway (only one of the three *.out files was distributed). Let me know if you need a PR for this one in master.

@thbeu
Copy link
Contributor

thbeu commented Mar 6, 2024

I believe that all files in tests/shape_eg_data/ also need to be part of the distribution to make the test1.sh passing.

test-suite.log

@rouault
Copy link
Member

rouault commented Mar 9, 2024

@thbeu Not sure if you want to pursue this, but maybe create a new PR then ?

@thbeu thbeu mentioned this pull request Mar 9, 2024
1 task
@thbeu
Copy link
Contributor

thbeu commented Mar 9, 2024

OK, there now is #110 which superseds this PR.

@rouault rouault closed this Mar 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants