You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed in some comment threads in #566 (like this one), attempting to run some of DMOD tests will fail the code was not obtained by cloning the repo via Git. This is because Git-based functionality is utilized as a step to determining the correct path for testing files.
This approach was adopted because it satisfied two requirements:
avoiding use of absolute paths
tests could be executed from any working directory within the repo directory structure
The reason the first item is required is fairly clear, but I don't remember exactly why the second is. I believe it has to do with the way certain test tools (perhaps our tests scripts also) run tests, and also the way certain IDEs execute tests when run through their interface.
In the interests of compatibility, we should explore whether there is an alternative, more general method that still satisfies our current needs with respect to automated testing.
The text was updated successfully, but these errors were encountered:
An approach I've used before here was acknowledging a known pattern for the root directory and climbing up the directory chain from the CWD to the root to find a directory that fits the profile. In bash, I did:
path=$(realpath .);while [ "$path"!="/" ];do# Get the base name of the directory in lower case - for something like 'Path/To/DiReCtOrY', this will yield# 'directory'
lowercase_base=$(basename "$path"| tr "[:upper:]""[:lower:]")# Check if the directory name is some form of 'dmod' and that it contains a 'scripts' and 'python' directoryif [ "$lowercase_base"="dmod" ] && [ -d"${path}/scripts" ] && [ -d"${path}/python" ];then# If it exists, echo the path so it may be caught by the caller and exit the functionecho"$path"return 0;fi# Reassign path investigate the parent
path=$(dirname "$path");done
It's ugly as hell, but it got the job done in the one case I tried it. Maybe that'll help as a jumping off point.
Austin has also stated in the past that moving 100% over to pytest over unittest will provide utilities for making sure all the tests can find the resources.
I think the easiest thing we can do is just look for the .github directory in the root of the repo. We shouldn't expect that to be anywhere but the root.
As discussed in some comment threads in #566 (like this one), attempting to run some of DMOD tests will fail the code was not obtained by cloning the repo via Git. This is because Git-based functionality is utilized as a step to determining the correct path for testing files.
This approach was adopted because it satisfied two requirements:
The reason the first item is required is fairly clear, but I don't remember exactly why the second is. I believe it has to do with the way certain test tools (perhaps our tests scripts also) run tests, and also the way certain IDEs execute tests when run through their interface.
In the interests of compatibility, we should explore whether there is an alternative, more general method that still satisfies our current needs with respect to automated testing.
The text was updated successfully, but these errors were encountered: