-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
testing: test failes if leaving files without write permission in T.TempDir #40853
Comments
Maybe this is bug of |
I think this is a reasonable error. If the test does something that the test harness cannot undo there should be some indication to the user. |
I updated the test. @davecheney |
@atetubou would you be able to do the same test by hand in a shell, I think this is a Unix permissions quirk. |
@davecheney sorry, what do you mean by |
I would expect the 'bash' equivalent to do |
Ah, I see; even |
I don’t think there is anything here to fix. If the test creates a directory with cannot be removed then the cleanup code should highlight this because this kind of test is not very hermetic. |
Previous to T.TempDir the test was managing its own temporary directory, and had its own implementation of RemoveAll, since RemoveAll doesn't do stat changes to remove all that the process has permission to remove. The code under test manipulates the permissions of the files it creates intentionally; I'm not sure what hermeticity has to do with it. From my PoV, the TempDir provided by the test should only fail to remove if the test process has no permissions sufficient to remove it. Other than "os.RemoveAll doesn't remove everything that it could", is there a reason why the current behavior of t.TempDir is desirable? |
Simplicity. Why add complexity for a case that essentially never arises? Let's just document the restriction: don't create unwritable directions in the directory returned by |
I can see that not addressing this case in testing will make the testing package simpler by making tests which run into this more complex. By definition, code which needs to create directories with different chmod values will not use this functionality (in case you're using "usage of t.TempDir" as the basis for "essentially never arises". Since t.TempDir is new for 1.15, I find it a bit early to make a claim about this essentially never happening.) IMO interface simplicity and implementation simplicity are a tradeoff, and for testing code I would definitely err on the side of making the interface simpler in order to make the tests simpler, since burying the important test bits with infrastructure makes the tests less pithy. Is there a general recommendation here that Go programs should not create folders without u+x? Or that such code should not be tested? |
Maybe I can make the case that testing the operation of code in the presence of specific permissions on disk is not the majority of the test code written for go programs. I think the majority of the standard library supports this position, as does the corpus of open source code I’ve been exposed too. For the cases where the test is specifically setting a condition where the code under test would fail — if the real code can’t remove that directory, what chance does a test helper have — there is t.Cleanup where the author of the test has a chance to hook the test tear down and assist. |
Yes. To me that seems like the right tradeoff, given my belief that very very few tests need to create temporary unwritable directories, and that it is still possible to write such tests using |
Note that the code under test has the purpose of preparing this directory, in production the 'real code' does not remove it. The directory is later removed by a different program (which does successfully remove w/ chmod). From my PoV the "effort" that os.RemoveAll makes is arbitrary; It knows how to do a depth-first recursion, but doesn't know how to do chmod. It also not really what I would call "simple" (https://golang.org/src/os/removeall_at.go). The current implementation already pays for the 'stat' call necessary to see the permission bits on intermediate nodes*, too, for example.
Yes, that's what our tests will need to continue to do.
I do, but I respect your position here; there is no 'right' answer here, only tradeoffs and different weights for those tradeoffs :) edit: s/modes/nodes |
The use testing.T.TempDir() seems to cause test failures in CI environvements in those cases where temporary directories' subdirs are created with permissions that are different from the defaults used by testing.T.TempDir(). The snapshots package's tests seem to be heavily affected, thus this replaces testing.T.TempDir() occurrences with ioutil.TempDir() calls. Related upstream issue: - golang/go#40853
The use testing.T.TempDir() seems to cause test failures in CI environvements in those cases where temporary directories' subdirs are created with permissions that are different from the defaults used by testing.T.TempDir(). The snapshots package's tests seem to be heavily affected, thus this replaces testing.T.TempDir() occurrences with ioutil.TempDir() calls. Related upstream issue: - golang/go#40853 Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I wrote a test leaving a file without write permission.
What did you expect to see?
Both test passed.
What did you see instead?
Only
TestNoDir
passed.The text was updated successfully, but these errors were encountered: