0

I am writing a unit test for a package in golang. I need to create a variable of private field type which resides in a different package to pass it as a parameter to the function that I am testing.

package : go/abc/a.go

type newType int

package : go/edf/b.go

import "go/abc"

func init(abc newType){
  // ommitted for brevity 
}

Now I am writing unit test for b.go say

package : go/edf/b_test.go

func TestInit(){
// Now I need to create a variable of private field type newType in abc package
// for passing as parameter to the init function....   
}

Is it possible to achieve this using reflect or packages package in golang

naveen
  • 560
  • 6
  • 15
  • note that in Go top-level `init` functions are reserved for pre-main-execution initialization. And they are required that their type is `func()` (no input args, no output args), therefore your `func init(abc newType) {` will fail to compile even if it had access to `newType`, which it doesn't. – mkopriva Jul 29 '21 at 09:22

1 Answers1

2

I need to access a private field in a package

You cannot do this. The sole purpose of being unexported (what you call private) is to be inaccessable from outside.

Volker
  • 40,468
  • 7
  • 81
  • 87
  • But the same is possible in other programming languages say java.... – naveen Jul 29 '21 at 08:57
  • I somehow accessed the private field metadata information using the "packages" package in golang – naveen Jul 29 '21 at 08:58
  • 1
    @naveen if by "'packages' package" you mean `golang.org/x/tools/go/packages` package then you should know that that package deals with Go source code and not the runtime. If you want to access something *at runtime* you better make sure it's exported, i.e. not private. – mkopriva Jul 29 '21 at 09:07
  • @naveen also note that just because some languages allow accessing of private properties through reflection, that does not mean that every other language has to follow suit. – mkopriva Jul 29 '21 at 09:09
  • 2
    @naveen _"But the same is possible in other programming languages say java...."_ What's possible in other languages is irrelevant in Go. – icza Jul 29 '21 at 09:09
  • @mkopriva Can any source confirm this? say some section in Go language specification – Amrish Kumar Jul 29 '21 at 09:17
  • @AmrishKumar confirm what? – mkopriva Jul 29 '21 at 09:19
  • source to confirm that this is not possible using reflection, if a un-exported field struct can be accessed through reflection why not global variables? The OP has asked whether this is possible using reflection or other – Amrish Kumar Jul 29 '21 at 09:20
  • @AmrishKumar https://play.golang.org/p/lZqX_6Ua_uS -- can you show that you can, using reflection, access the field `f` of type `s` from package `foo` **without** first introducing an *exported* func that returns an instance of `s`, or an *exported* type that contains `s`, or an *exported* variable that holds `s`, etc...? – mkopriva Jul 29 '21 at 09:33
  • @AmrishKumar If I tell you that 1+1 = 2: Will you ask for a source confirming this? Why do obvious _facts_ need sources? If reflection would break accessability package reflect would have a bug. No there is no source confirming that paskage reflect does not have any bug. – Volker Jul 29 '21 at 09:44
  • I used to work with Java, where the JLS deeply details why something is designed/works the way it is. I was curious to know same on Go lang. Understood that the obvious can't be broken down – Amrish Kumar Jul 29 '21 at 10:03