Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to test a unexported (private) function in go (golang)?

I was interested in creating unit test for "unexported (private) functions" in go. However, its basically really hard to create unit tests form them in the test package because I have to make them "public". Which in the end, defeats the whole point of them being private. The point is that these helper function help modularize and now that they are modular, it would be nice to be able to create unit tests for them without making them available to everyone except the testing package, nice they are not functions that should be accessed or used by anyone else except the testing suite or the actual package itself.

Any suggestions? Is it possible to only export to its own package and 1 additional package or something of that sort in go?

like image 331
Charlie Parker Avatar asked Jul 08 '14 01:07

Charlie Parker


People also ask

How do you test a function in go?

At the command line in the greetings directory, run the go test command to execute the test. The go test command executes test functions (whose names begin with Test ) in test files (whose names end with _test.go). You can add the -v flag to get verbose output that lists all of the tests and their results.

Should you test private methods Golang?

You should obviously ensure your private method works, but you shouldn't have tests coupling you to the private method, because it is not part of the use case of the software.

How do you test concurrency in go?

If you want to test concurrency you'll need to make a few go routines and have them run, well, concurrently. You might try taking the locking out and intentionally get it to crash or misbehave by concurrently modifying things and then add the locking in to ensure it solves it.


2 Answers

create a test file within the package

library_test.go

package mypkg  func TestPrivateStruct(t *testing.T){   pf := private{ "Private Field" }   .... } 

library.go

package mypkg  type private struct {   privateField string } 

go test mypkg -v will run your Tests with your private struct

like image 125
fabrizioM Avatar answered Oct 02 '22 13:10

fabrizioM


First, you can have both types of tests in the same location as your package by using the package name for internal tests (eg mypkg) and using the same package name with "_test" appended for "external" tests (eg mypkg_test). Both types of tests must be in files whose name ends in "_test.go".

BUT, the whole point of unit tests is to test the "external interface" (ie public functions) to your package. That is unit tests should always be "white box" tests (see White Box Testing). That way you can refactor your code and your tests won't break.

Of course, sometimes you want to check internal consistency, which is not possible through the "external interface". For that I have found assertions invaluable. Another possibility would be to add public "diagnostic" function(s) with names that indicate that they are not for normal use.

like image 32
Andrew W. Phillips Avatar answered Oct 02 '22 11:10

Andrew W. Phillips