Creating a test go script shadows the actual custom module scripts

nkakouros commented 6 years ago

Due diligence

[x] I am familiar with the "Reporting issues" section of CONTRIBUTING.md
[x] I have searched the existing issues and haven't found one that matches what I'm reporting or requesting now.
[x] If this is a bug report, I have searched the Bash changelog for information that may explain or provide clues to the behavior I'm observing and reference it in the body of the report.

Framework, Bash, and operating system version information

_GO_CORE_VERSION:         v1.7.0
BASH_VERSION:             4.4.19(1)-release
OSTYPE:                   linux-gnu
_GO_PLATFORM_ID:          arch
_GO_PLATFORM_VERSION_ID:

Description

When creating a test go script using @go.create_test_go_script() and using run "$TEST_GO_SCRIPT", the paths are set so that the actual directory where the project's modules are is not taken into account when resolving the path to a module.

For example:

@test 'test' {
  @go.create_test_go_script '"$_GO_USE_MODULES" archive custom_module'
  run "$TEST_GO_SCRIPT"
  assert_success
}

will fail with an error like:

     `assert_success' failed
   expected success, but command failed
   STATUS: 70
   OUTPUT:
   ERROR: Module custom_module not found at:
     /.../scripts/vendor/go-script-bash/lib/internal/use:184 source
     /.../tmp/test rootdir/go:3 main

The reason is that the test go script is in a directory different to the actual project's go script. As a result the _GO_ROOTDIR=${0%/*} variable is set to the temporary test directory and the _GO_SCRIPTS_DIR is then resolved relative to that directory.

A way to avoid this error is to set the TEST_GO_ROOTDIR, TEST_GO_SCRIPTS_RELATIVE_DIR, etc mentioned in lib/testing/environment to custom values in a custom environment file so that effectively the TEST_* paths coincide with the actual _GO_* paths. But this defeats the purpose of the TEST_* variables (as I understand it) which is to create a sandbox directory where transient files will be written to and deleted without the fear of messing up the actual project.

Is my understanding of the above correct? Is this behavior by design or a limitation of the current design? In the latter case, there could be one more variable, TEST_REAL_GO_ROOTDIR that, if set, will set _GO_ROOTDIR in go-core.bash directly (as opposed to reading it from $0).

Edit: My use case is that my entry go script loads a number of modules regardless of the command. Then, a command might use a function that requires 4 modules. That could mean ~8 modules for a function to run correctly. It seems to me that copying or stubbing all 8 modules just to test one function is not the appropriate solution. But I might be wrong.

nkakouros commented 6 years ago

I ended up copying any needed file for a test to TEST_GO_ROOTDIR/.... I am leaving this open just in case @mbland has some insight to share.

nkakouros commented 5 years ago

Closing this as the design of the testing framework is indeed great and my solution is sufficient for my use case.

mbland / go-script-bash