12. Code Testing
by Mat Ryer, Mario Castro Contreras, Vladimir Vivien
Go: Design Patterns for Real-World Projects
- Go: Design Patterns for Real-World Projects
- Go: Design Patterns for Real-World Projects
- Credits
- Preface
- 1. Module 1
- 1. A First Step in Go
- 2. Go Language Essentials
- 3. Go Control Flow
- 4. Data Types
- 5. Functions in Go
- 6. Go Packages and Programs
- 7. Composite Types
- 8. Methods, Interfaces, and Objects
- 9. Concurrency
- 10. Data IO in Go
- 11. Writing Networked Services
- 12. Code Testing
- 2. Module 2
- 1. Ready... Steady... Go!
- A little bit of history
- Installing Go
- Starting with Hello World
- Integrated Development Environment - IDE
- Types
- Variables and constants
- Operators
- Flow control
- Functions
- Arrays, slices, and maps
- Visibility
- Zero-initialization
- Pointers and structures
- Interfaces
- Testing and TDD
- Libraries
- The Go get tool
- Managing JSON data
- Go tools
- Contributing to Go open source projects in GitHub
- Summary
- 2. Creational Patterns - Singleton, Builder, Factory, Prototype, and Abstract Factory Design Patterns
- Singleton design pattern - having a unique instance of a type in the entire program
- Builder design pattern - reusing an algorithm to create many implementations of an interface
- Factory method - delegating the creation of different types of payments
- Abstract Factory - a factory of factories
- Prototype design pattern
- Summary
- 3. Structural Patterns - Composite, Adapter, and Bridge Design Patterns
- 4. Structural Patterns - Proxy, Facade, Decorator, and Flyweight Design Patterns
- 5. Behavioral Patterns - Strategy, Chain of Responsibility, and Command Design Patterns
- 6. Behavioral Patterns - Template, Memento, and Interpreter Design Patterns
- Template design pattern
- Description
- Objectives
- Example - a simple algorithm with a deferred step
- Requirements and acceptance criteria
- Unit tests for the simple algorithm
- Implementing the Template pattern
- Anonymous functions
- How to avoid modifications on the interface
- Looking for the Template pattern in Go's source code
- Summarizing the Template design pattern
- Memento design pattern
- Interpreter design pattern
- Summary
- Template design pattern
- 7. Behavioral Patterns - Visitor, State, Mediator, and Observer Design Patterns
- 8. Introduction to Gos Concurrency
- 9. Concurrency Patterns - Barrier, Future, and Pipeline Design Patterns
- 10. Concurrency Patterns - Workers Pool and Publish/Subscriber Design Patterns
- 1. Ready... Steady... Go!
- 3. Module 3
- 1. Chat Application with Web Sockets
- 2. Adding User Accounts
- 3. Three Ways to Implement Profile Pictures
- 4. Command-Line Tools to Find Domain Names
- 5. Building Distributed Systems and Working with Flexible Data
- 6. Exposing Data and Functionality through a RESTful Data Web Service API
- 7. Random Recommendations Web Service
- 8. Filesystem Backup
- 9. Building a Q&A Application for Google App Engine
- The Google App Engine SDK for Go
- Google Cloud Datastore
- Entities and data access
- Google App Engine users
- Transactions in Google Cloud Datastore
- Querying in Google Cloud Datastore
- Votes
- Casting a vote
- Exposing data operations over HTTP
- Running apps with multiple modules
- Deploying apps with multiple modules
- Summary
- 10. Micro-services in Go with the Go kit Framework
- 11. Deploying Go Applications Using Docker
- Appendix. Good Practices for a Stable Go Environment
- Bibliography
Testing is a critical ritual of modern software development practices. Go brings testing directly into the development cycle by offering an API and command-line tool to seamlessly create and integrate automated test code. Here we will cover the Go testing suite, including the following:
- The Go test tool
- Writing Go tests
- HTTP testing
- Test coverage
- Code benchmark
Prior to writing any test code, let's take a detour to discuss the tooling for automated testing in Go. Similar to the go build command, the go test command is designed to compile and exercise test source files in specified packages, as illustrated in the following command:
$> go test .
The previous command will exercise all test functions in the current package. Although it appears to be simple, the previous command accomplishes several complex steps, including:
- The compilation of all test files found in the current package
- Generating an instrumented binary from the test file
- Executing the test functions in the code
When the go test command targets multiple packages, the test tool generates multiple test binaries that are executed and tested independently, as shown in the following:
$> go test ./...
The test command uses the import path standard (see Chapter 6, Go Packages and Programs) to specify which packages to test. Within a specified package, the test tool will compile all files with the *_test.go name pattern. For instance, assuming that we have a project that has a simple implementation of a mathematical vector type in a file called vec.go, a sensible name for its test file would be vec_test.go.
Traditionally, test files are kept in the same package (directory) as the code being tested. This is because there is no need to separate tests files, as they are excluded from the compiled program binary. The following shows the directory layout for a typical Go package, in this instance the fmt package from the standard library. It shows all of the test files for the package in the same directory as the regular source code:
$>tree go/src/fmt/ ├── doc.go ├── export_test.go ├── fmt_test.go ├── format.go ├── norace_test.go ├── print.go ├── race_test.go ├── scan.go ├── scan_test.go └── stringer_test.go
Besides having a simpler project structure, keeping the files together gives test functions full visibility of the package being tested. This facilitates access to and verification of package elements that would otherwise be opaque to testing code. When your functions are placed in a separate package from the code to be tested, they lose access to non-exported elements of the code.
-
No Comment