2

I have 2 files in the same package.

# my_package1/my_file1.go

func myFunc1() {
  //....
} 

# my_package1/my_file1_test.go

type MyPackageSuite struct {
  suite.Suite
}

func (s *MyPackageSuite) MyTest1() {
  //...............

  res1 := myFunc1()

  //...............
}

I run a test go test my_package1/my_file1_test.go -v and it returns undefined: myFunc1

But they're in the same package. Why the error? How to fix it? Making the method public isn't what I'm looking for.

Update1:

$ ls webhook
doc.go      webhook.go  webhook_test.go

Then

$ go test webhook
can't load package: package webhook: malformed module path "webhook": missing dot in first path element


$ go test webhook/webhook
can't load package: package webhook/webhook: malformed module path "webhook/webhook": missing dot in first path element

$ go test webhook/webhook.go
?     command-line-arguments  [no test files]


$ go test webhook/webhook_test.go 
# command-line-arguments [command-line-arguments.test]
webhook/webhook_test.go: undefined: myFunc1
FAIL  command-line-arguments [build failed]
FAIL
stizzo96
  • 666
  • 1
  • 7
  • 15
Totto
  • 73
  • 1
  • 6
  • 2
    Do not run the test using file name. Either cd under the package and run go test, or run go test . – Burak Serdar Dec 03 '19 at 05:50
  • @BurakSerdar see my update – Totto Dec 03 '19 at 06:14
  • 1
    If it is complaining about import cycle, you're importing the same package. Don't do that. If you're using go modules, use full package path: go test moduleName/webhook. If not, use relative package dir: go test ./webhook. go test webhook tries to test a package named `webhook`, and since it does not have a hostname as first component, it assumes it is a stdlib package. – Burak Serdar Dec 03 '19 at 06:24
  • @BurakSerdar running `go test` from the directory of the package causes `import cycle not allowed in test`. Otherwise, **without this test with the private method**, it works. That is, this works if I don't use the test with the private method --> `go test webhook/webhook_test.go` – Totto Dec 03 '19 at 06:25
  • @BurakSerdar - no. Read my last comment. – Totto Dec 03 '19 at 06:26
  • The `go` tool works on packages (there are some modes to work with files, but they are best avoided in most cases). If you cannot run a simple `go test` (e.g. because of an import cycle or because you misspelled your package in test) then your package setup is **broken** and **must** be fixed. No arguing here. Go **forbidds** import cycles and **requires** one of two package names in _test.go files. – Volker Dec 03 '19 at 06:32
  • 1
    If you want to test the exported boundary of some `package p` and have a p_test.go file declaring itself as `package p_test` then you **cannot** access unexported stuff from p. This is _by_ _design_ and **cannot** be circumvented by ugly tricks. Just stop doing this. – Volker Dec 03 '19 at 06:34
  • ... See [relative import paths](https://golang.org/cmd/go/#hdr-Relative_import_paths) ... *"a relative path can be used as a shorthand on the command line. If you are working in the directory containing the code imported as "unicode" and want to run the tests for "unicode/utf8", you can type `"go test ./utf8"` instead of needing to specify the full path."* But keep in mind what Volker said, for a file to be able to access an unexported identifier it must declare the same package as the file declaring the identifier. – mkopriva Dec 03 '19 at 07:03

1 Answers1

1

Try go test ./my_package1 to force the compilation of the all package.
Or at least a go build first.

The idea is to make sure myFunc1() was compiled before executing the test file.

The "malformed module path" "missing dot in first path element" suggests a go mod file is missing:

cd /path/to/project
go mod init project
go test ./webhook
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • @Totto Can you try `go test ./webhook`? Do you have a `go.mod` file in your project? – VonC Dec 03 '19 at 07:01