If you’re looking for something assertion-like, that’s if foo { panic("bug: foo happened") }. The cases where that’s warranted are few and far between
though, think “something happened that proves our assumptions are wildly incorrect and continuing at this point will eat the user’s data”.
For something of note that should end up in the log, use l.Infoln. If it’s something serious and actionable that the user can fix use l.Warnln.
Exactly. I think this is one of the places when if something gets wrong, data loss can occur.
Keeping in mind that Syncthing will be dead in the water and the action will probably be retried repeatedly with the same crash. So if there’s a safer option, better take that.
l.Warnf() seems to have a negative side effect that is it displayed to the user every time the warning is issued. Is there a way to show it only once, or once a day, or so?
I have tested mine changes on Windows. How can I test that it works on Linux etc. too? Would you test it after I send the pull request? Or what are my options?
If you need that kind of logic it needs to be implemented manually. We have similar things in some places.
If you create a unit test it will be run on Windows/Linux/Mac by the builders.
How can I execute a particular unit test (e.g. walkfs_test.go)?
I need to create a Windows specific test. Would it work if I simply create walkfs_windows_test.go, or do I have to do something more?
Do I have to make cleanup, or the tests are executed with a clean filesystem? testWalkSkipSymlink() does no cleanup.
I’ll have to create a directory junction using system osexec.Command("cmd", "/c", "mklink", ...) or something like that.
Tests should clean up after themselves. (Maybe it doesn’t, but it should.) Keep in kind you can’t assume the tests run with admin privileges. It may not be feasible to automatically create junctions and test traversing them. There may be other aspects you can reasonably test.
Could you please advise me, how to run a unit test?
go test -run lib/fs/walkfs_test.go
doesn’t work.
go test -run=NameOfTestFunction but this has to be in a package directory.
You can omit the -run part and it will run for the whole package.
Alternatively, you can do go test github.com/syncthing/syncthing/lib/fs which is the import path to test.
Thank you, but I always get
can't load package: package .: build constraints exclude all Go files in <syncthing_src_root>
when run from the <syncthing_src_root>
Source root does not contain any source code, the code is either in cmd/something or lib/something.
You can just run ./build.sh test if you want to just run all tests.
I want to run that single test only, I do not know what running all the tests would do on my computer.
C:\Workspaces\Syncthing\lib>go test -run=fs/walkfs_test
can't load package: package .: no Go files in C:\Workspaces\Syncthing\lib
C:\Workspaces\Syncthing\lib>go test fs/walkfs_test
can't load package: package fs/walkfs_test is not in GOROOT (C:\Program Files\go\src\fs\walkfs_test)Run takes a function name, not a directory. The non-run argument takes a fully qualified (not relative) go package name (import path), not a directory.
C:\Workspaces\Syncthing\lib>go test -run=fs.testWalkSkipSymlink
can't load package: package .: no Go files in C:\Workspaces\Syncthing\lib
C:\Workspaces\Syncthing\lib>go test -run=fs/testWalkSkipSymlink
can't load package: package .: no Go files in C:\Workspaces\Syncthing\lib
C:\Workspaces\Syncthing\lib>go test -run=fs/walkfs_test.go/testWalkSkipSymlink
can't load package: package .: no Go files in C:\Workspaces\Syncthing\lib
I simply don’t know. Could you please write me down a command that works?
Tests have to be “public”, so they have to start with a capital letter, and take *testing.T as an argument.
Then:
cd fs
# run a specific test
go test -run=NameOfTest
# run all tests
go test
or
go test github.com/syncthing/syncthing/lib/fs -name=NameOfTest
The first option (when I have to cd to the fs directory) works for me, thank you.
Edit: The second option works too:
go test C:\Workspaces\Syncthing\lib\fs -run=TestBasicWalkSkipSymlink
The path must be absolute, and -run must be used, not -name.
It seems to work for me with packages:
/cygdrive/c/Gohome/src/github.com/syncthing/syncthing $ go test github.com/syncthing/syncthing/lib/fs
ok github.com/syncthing/syncthing/lib/fs 0.639s
Perhaps go version/module support enabled disabled/where is GOPATH/GOROOT difference.
It also works with explicitly relative paths (at least on linux), i.e. they must be preceeded by ./. E.g. go test ./lib/model -run SomeTest works, while go test lib/model -run SomeTest does not.
The “explicit” relative paths (starting with “.” or “…” (two dots, I don’t understand why it it shown as three dots)) work even on Windows, thank you.
A pull request created. We can bring the discussion about the code there. I need your assistance there, as it seems to me that the failed tests are not related with my code changes.