4 ms·

What does "files ... consulted by that run" mean? Does it track file/directory operations that occur during a test? I'm a heavy user of table-driven tests that

What does "files ... consulted by that run" mean? Does it track file/directory operations that occur during a test? I'm a heavy user of table-driven tests that typically use YAML files that set up the parameters for the test scenarios. These use filepath.Glob(), ioutil.ReadDir(), and so on. For "go test" to invalidate its cache correctly, it would have to intercept those calls and record the dependencies. That'd be awesome.

Scaevolus 9y ago
Only source files, unfortunately. You could use a caching build system like Bazel to fork with data-driven tests, but most users don't need that functionality. It would be nice if tests could give hints like t.DisableCache() or t.DependsOn(filename).
- uluyol 9y ago
  I think this is misinformation. go test does track files read during tests and records a hash of their contents. Bug: https://github.com/golang/go/issues/22593 https://github.com/golang/go/issues/22593 Commit: https://go-review.googlesource.com/c/go/+/81895 https://go-review.googlesource.com/c/go/+/81895
- lobster_johnson 9y ago
  I looked at the code mentioned in the sibling comment. They do track file access. Incredibly, they've modified the standard library (os.Exec(), Stat() and so on) to log the activity to an internal mechanism used by the testing package. I'm rather flabbergasted by the close coupling (it's a feature that would've been impossible for anyone outside the Go team to implement), though it's certainly a pragmatic solution. Tracking seems to only occur within the current process, so if you call out to a subprocess to generate files, those files won't be taken into account, but I've not gone through the code with a fine comb.
  - HankB99 9y ago
    In other words, there are ways to 'fool' the dependency tree. My first thought was that this might be a contrived situation. Then I realized I have exactly that in a project I'm presently working on. It does a lot of file system operations and I use shell scripts invoked from test code to set up files for testing. I'll have to investigate how to force tests to run if I change test scripts. I suppose changing the `go` test case to result in a test failure and then modifying the script to produce correct results (or a valid failure ;) ) would do the trick. I guess changing the scripts would be detected by `go` so perhaps I don't have a problem. At present none of my scripts invoke other scripts.
    - HALtheWise 9y ago
      Just read the scripts from your test function, then go will check their hashes and rerun the test if they changed.

Scaevolus 9y ago

Only source files, unfortunately. You could use a caching build system like Bazel to fork with data-driven tests, but most users don't need that functionality. It would be nice if tests could give hints like t.DisableCache() or t.DependsOn(filename).

uluyol 9y ago
I think this is misinformation. go test does track files read during tests and records a hash of their contents. Bug: https://github.com/golang/go/issues/22593 https://github.com/golang/go/issues/22593 Commit: https://go-review.googlesource.com/c/go/+/81895 https://go-review.googlesource.com/c/go/+/81895
lobster_johnson 9y ago
I looked at the code mentioned in the sibling comment. They do track file access. Incredibly, they've modified the standard library (os.Exec(), Stat() and so on) to log the activity to an internal mechanism used by the testing package. I'm rather flabbergasted by the close coupling (it's a feature that would've been impossible for anyone outside the Go team to implement), though it's certainly a pragmatic solution. Tracking seems to only occur within the current process, so if you call out to a subprocess to generate files, those files won't be taken into account, but I've not gone through the code with a fine comb.
- HankB99 9y ago
  In other words, there are ways to 'fool' the dependency tree. My first thought was that this might be a contrived situation. Then I realized I have exactly that in a project I'm presently working on. It does a lot of file system operations and I use shell scripts invoked from test code to set up files for testing. I'll have to investigate how to force tests to run if I change test scripts. I suppose changing the `go` test case to result in a test failure and then modifying the script to produce correct results (or a valid failure ;) ) would do the trick. I guess changing the scripts would be detected by `go` so perhaps I don't have a problem. At present none of my scripts invoke other scripts.
  - HALtheWise 9y ago
    Just read the scripts from your test function, then go will check their hashes and rerun the test if they changed.