Table-driven test
A table-driven test represents multiple test cases as data records and applies a common testing procedure to each case.
Learn Go with Pocket-Sized Projects
Table-driven testing is a testing technique that represents multiple input-output scenarios as structured test cases processed by shared test logic.
- How it is used
- Replaces repeated function tests with named input-output cases processed by shared test logic.
- How deep it goes
- Works through case structs, a map of scenarios, subtests, and comparisons; extends the procedure to errors and structured results.
- Examples
- Uses multilingual greetings, JSON file-loading outcomes, and word-game feedback to exercise ordinary and edge-case behavior.
- What you can do after
- Build it from scratch for a Go function, then add named cases without duplicating execution and assertion logic.
Read how Learn Go with Pocket-Sized Projects explains table-driven test →
Go by Example
Table-driven testing is a testing technique that represents multiple test cases as data and executes a common test procedure for each case.
- How it is used
- Organizes repeated Go function checks into reusable test data and one shared assertion procedure.
- How deep it goes
- Works through table declaration, iteration, logging, assertions, execution filtering, and fatal-failure limitations before deferring isolation to subtests.
- Examples
- Demonstrates Parse against full, pathless, and data-scheme URL cases stored in an anonymous struct slice.
- What you can do after
- Apply it in Go tests to add scenarios as data while reusing one test procedure.
Shipping Go: Develop, deliver, discuss, design, and go again
Table-driven testing defines multiple test cases as structured data and executes a common test procedure for each case.
- How it is used
- Uses case tables to simplify translation tests and expand HTTP handler coverage as behavior changes.
- How deep it goes
- Works through struct-based cases, shared checks, and incremental additions without discussing test-framework internals.
- Examples
- Tests translations across languages, then checks HTTP language queries and a missing-translation 404.
- What you can do after
- Practice/perform refactoring repeated Go tests into case tables and adding cases that expose missing behavior.
Read how Shipping Go: Develop, deliver, discuss, design, and go again explains table-driven test →
100 Go Mistakes and How to Avoid Them
A table-driven test organizes multiple test cases as data and applies shared testing logic to each case.
- How it is used
- Reduces duplicated unit-test code by representing similar cases as data and applying one testing procedure.
- How deep it goes
- Explains case tables, subtests, selective execution, and parallel-test loop-variable handling, without broader test design.
- Examples
- Uses newline-suffix removal cases covering empty, newline, carriage-return/newline, repeated-newline, and unchanged inputs.
- What you can do after
- Apply via Go subtests by defining case data once and reusing shared invocation and comparison logic.
Read how 100 Go Mistakes and How to Avoid Them explains table-driven test →
Go in Action, Second Edition
A table-driven test represents multiple test cases as data records and runs a common test procedure over them.
- How it is used
- Simplifies repetitive Go tests by separating varying case data from shared execution and assertion logic.
- How deep it goes
- Explains struct design, slice construction, looping, logging, and maintenance benefits, but does not develop advanced table-test variations.
- Examples
- Uses Calculator operations and HTTP GET, POST, and unsupported-method handler cases as concrete test tables.
- What you can do after
- Apply the pattern by defining case records, iterating over them, logging inputs, and asserting each result with go test.
Read how Go in Action, Second Edition explains table-driven test →
Go in Practice, Second Edition
A test table is a collection of input and expected-result records used to exercise multiple conditions against a test target.
- How it is used
- Organizes unit tests around multiple input and expected-output cases instead of relying on manual output inspection.
- How deep it goes
- Defines the table, iteration, assertion, failure inspection, and case expansion, but does not cover subtests or benchmarks.
- Examples
- Uses Fizz Buzz cases for inputs 37, 5, and 12, including expected strings and failing or passing go test output.
- What you can do after
- Diagnose implementation errors and extend coverage by adding input and expected-result records.
Read how Go in Practice, Second Edition explains table-driven test →
Related concepts
- testuses · A test is a procedure or check that evaluates behavior using specified inputs or evidence against expected results or criteria.
- structuses · A struct is a composite data type or structure that groups related fields or values into a single unit.
- subtestuses · A subtest is an independently named test execution nested within a parent test and reported separately.
- Mapused by · A map is an associative data structure that stores key-value pairs and supports retrieving values by key.
- Fatalfcontrasts with · Fatalf is a testing method that records a formatted failure message and immediately terminates the calling test function.
- slicinguses · Slicing selects or partitions a portion of an indexed sequence or multidimensional array, often along specified indices or dimensions.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.