liveBook · Manning

T.Errorf

As explained in Go by Example

testing.T.Errorf records a formatted test failure while allowing the calling test function to continue.

t.Errorf records a formatted failure for the current test function and then lets that function continue. Use it when a failed check is informative but does not make later checks unsafe or meaningless. It contrasts with t.Fatalf, which records failure and stops the calling test function immediately. section 2.3 section 2.3.1

Keep checking after a valid parse

A parser test first treats an error as fatal: without a valid URL, dereferencing the result could panic. Once parsing succeeds, it compares got with want and calls t.Errorf on a mismatch. The test can therefore report an incorrect parsed value without abandoning any subsequent independent checks. section 2.3.1

t.Errorf(
    "Parse(%q)\ngot  %#v\nwant %#v",  #1
    uri, got, want,
)

Format failures around the input and a readable got/want comparison. Newlines separate the values, and %#v prints Go-syntax representations so struct fields remain visible rather than invoking a String method through %s. section 2.3.4

Choose and shape t.Errorf calls deliberately:

  • Use t.Errorf for nonfatal mismatches; use t.Fatalf when the rest of the test depends on a failed operation succeeding. section 2.3.1
  • Include the operation or input, then show got and want values so failures can be diagnosed without immediately inspecting the tested implementation. section 2.3.4
  • For deeply nested or pointer-rich values, use cmp.Diff from go-cmp and report its diff through t.Errorf instead of relying on a difficult manual comparison. section 2.3.4
  • Keep each *testing.T with its own test function or subtest; a subtest receives its own *T and reports failures only for itself. section 2.5.3

Test a reassembled URL

A URL.String test builds a URL value, calls String, and compares the returned string with the expected URL. Because no later step depends on the comparison succeeding, a single t.Errorf is sufficient to report a mismatch. section 2.3.1

Nonfatal reporting helps a test produce a fuller picture of independent problems in one run. A fatal failure still affects only its own test function or subtest; other tests continue because tests run independently and subtests receive distinct *T values. section 2.3 section 2.5.3

How Go by Example covers it

How deep it goes
Demonstrates formatted got/want failures, readable value printing, and go-cmp diffs for complex comparisons.
Examples
Uses Parse and URL.String tests, plus a go-cmp diff for a mismatched URL struct.
What it assumes
Assumes basic Go test functions receiving *testing.T and teaches when failed checks require stopping execution.
What you can do after
Diagnose/debug with it by writing nonfatal got/want failures and readable diffs for test mismatches.
How it connects
Connects t.Errorf with t.Fatalf, *testing.T, go test, go-cmp, table-driven tests, and subtests.
Cover of Go by Example
liveBookmanning.com
Read Go by Example on liveBook Get the book at manning.com

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Go by Example. The section links point to the parts of the book it draws on.