Proper package naming for testing with the Go language

Dan

I have seen several different test package naming strategies within Go and wanted to know what pros and cons of each are and which one I should use.

Strategy 1:

File name: github.com/user/myfunc.go

package myfunc

Test file name: github.com/user/myfunc_test.go

package myfunc

See bzip2 for an example.

Strategy 2:

File name: github.com/user/myfunc.go

package myfunc

Test file name: github.com/user/myfunc_test.go

package myfunc_test

import (
    "github.com/user/myfunc"
)

See wire for an example.

Strategy 3:

File name: github.com/user/myfunc.go

package myfunc

Test file name: github.com/user/myfunc_test.go

package myfunc_test

import (
    . "myfunc"
)

See strings for an example.

The Go standard library seems to use a mixture of strategy 1 and 2. Which of all three should I use? It's a pain appending package *_test to my testing packages as it means I can't test my package private methods but maybe there is a hidden advantage I am not aware of?

Matthew Rankin

The fundamental difference between the three strategies you've listed is whether or not the test code is in the same package as the code under test. The decision to use package myfunc or package myfunc_test in the test file depends on whether you want to perform white-box or black-box testing.

There's nothing wrong with using both methods in a project. For instance, you could have myfunc_whitebox_test.go and myfunx_blackbox_test.go.

Test Code Package Comparison

  • Black-box Testing: Use package myfunc_test, which will ensure you're only using the exported identifiers.
  • White-box Testing: Use package myfunc so that you have access to the non-exported identifiers. Good for unit tests that require access to non-exported variables, functions, and methods.

Comparison of Strategies Listed in Question

  • Strategy 1: The file myfunc_test.go uses package myfunc — In this case the test code in myfunc_test.go will be in the same package as the code being tested in myfunc.go, which is myfunc in this example.
  • Strategy 2: The file myfunc_test.go uses package myfunc_test — In this case the test code in myfunc_test.go "will be compiled as a separate package, and then linked and run with the main test binary." [Source: Lines 58–59 in the test.go source code]
  • Strategy 3: The file myfunc_test.go uses package myfunc_test but imports myfunc using the dot notation — This is a variant of Strategy 2, but uses the dot notation to import myfunc.

Collected from the Internet

Please contact [email protected] to delete if infringement.

edited at
0

Comments

0 comments
Login to comment

Related

From Dev

Go language package structure

From Dev

Not getting proper data using json encoding for a structure in go language

From Dev

What is the proper way to organize / structure Go package folders and files?

From Dev

Go language: Using package name inside package scope (for Examples)

From Java

How can I do test setup using the testing package in Go

From Dev

How do you print in a Go test using the "testing" package?

From Dev

Proper unit testing with PostSharp

From Dev

Package naming convention

From Dev

Debian package naming convention?

From Dev

Debian package naming convention?

From Dev

Package structure naming convention?

From Dev

RPM Package naming

From Java

Go naming conventions for const

From Dev

Go JSON Naming strategy

From Dev

proper package installation in Ubuntu

From Dev

proper package installation in Ubuntu

From Dev

proper naming convention for junit test methods

From Dev

proper naming convention and standard for this code in C#

From Dev

ARB_sync and proper testing

From Dev

Proper unit testing in Visual Studio

From Dev

Proper Unit testing with large projects

From Dev

Testing multicast - not getting proper results

From Dev

Naming conventions of composed package names

From Dev

standard naming convention for servlet package?

From Dev

Functional Test Package Naming Conventions?

From Dev

Java package naming convention in worklight

From Dev

RPM Package Naming Convention/Limitations

From Dev

Debian package naming policy for soname

From Dev

Idiomatic way of naming Getters in Go