What's the Best Package Naming Strategy for Go Tests?

Proper Package Naming for Testing in Go

When writing tests for Go code, there are several strategies for naming the test package. Each strategy offers different advantages and disadvantages, depending on the type of testing desired.

Strategy 1: Using the Same Package Name

In this strategy, the test file uses the same package name as the code being tested. This allows access to non-exported identifiers, making it suitable for unit tests that require such access. However, it may lead to testing details leaking into the public API of the package.

Strategy 2: Using a Separate Package Name

Here, the test file uses a different package name, typically with a "_test" suffix. This separates the test code from the code being tested, ensuring that only exported identifiers are used. It is appropriate for black-box testing, which focuses on testing the functionality of the public API.

Strategy 3: Using a Variant with Dot Notation

This strategy is similar to Strategy 2, but the test file imports the package using the dot notation, e.g., ". 'myfunc'". This allows access to non-exported identifiers, but it keeps the test code separate from the tested code. It is suitable for white-box testing while maintaining a separation of concerns.

The Go standard library employs a mix of Strategy 1 and Strategy 2. Which strategy to use depends on the specific purpose of the tests. Both white-box and black-box testing can be valuable, requiring access to either non-exported or exported identifiers, respectively.

The above is the detailed content of What's the Best Package Naming Strategy for Go Tests?. For more information, please follow other related articles on the PHP Chinese website!