some test fails if test_exe ran from current directory other than build/test

[AryanGitHub]

Describe the bug if we run test_exe from some other folder than build/test then some test fails

To Reproduce Steps to reproduce the behavior:

1. build the project with the flag DTEST=ON in cmake
2. check current directory is not build/test, with help of pwd in Linux
3. run build/test/test_exe not from the current directory build/test folder.

Expected behavior It should not fail the tests

Screenshots

[  FAILED  ] 5 tests, listed below:
[  FAILED  ] DOTTest.ReadFromDotUndirected
[  FAILED  ] DOTTest.ReadFromDotUndirectedWeighted
[  FAILED  ] DOTTest.ReadFromDotDirected
[  FAILED  ] MTXTest.ReadFromMtxDirectedWeighted
[  FAILED  ] MTXTest.ReadFromMtxUndirectedWeighted

Desktop (please complete the following information):

• OS: Fedora Linux 38 (Workstation Edition) 64bit
• Version: 38

[sbaldu]

Yes, those are the tests where we read a graph from file (dot or mtx). If you run from some other folder the relative path is not correct anymore.

[AryanGitHub]

Yes, those are the tests where we read a graph from file (dot or mtx). If you run from some other folder the relative path is not correct anymore.

I think we can provide an absolute path from CMake to a variable, and pass it to the program.

[badumbatish]

Just ran into something like this on my personal project, modern CMake provides the optional named argument WORKING_DIRECTORY to be used together with add_test().

If nobody's gonna try this out i'll give it a try in the next couple weeks

[ZigRazor]

Ok @badumbatish !

[badumbatish]

i did some digging around. i'm not sure exactly how to do this, but i think the add_test() working_directory option doesn't affect the working directory on the implementation in OutputOperation_impl.hpp and InputOperation_impl.hpp.

It'd be better if we refactor, for example, writeToDotFile() to accept a std::ofstream File instead of a working dir and file name. This way, we would open a a file in these tests* and pass in the file object instead.

I'm not sure how you feel about this

[ZigRazor]

could be a good alternative! you can implement it, aso because after the #427 we need to do a new major release and we can change also the interface!

[badumbatish]

sounds good to me, can i be notified when #427 is finished and MacOS related issues are merged? @ZigRazor

[ZigRazor]

YES, Sure!