liveBook · Manning

Fatalf

As explained in Go by Example

testing.T.Fatalf records a formatted test failure and stops execution of the calling test function.

Fatalf records a formatted test failure and immediately stops the current test function. Use it when continuing would make later checks invalid or unsafe. section 2.3 section 2.3.1

Use Fatalf when:

  • A required operation returns an error and the remaining assertions depend on its success. section 2.3.1
  • Continuing could trigger an unsafe operation, such as dereferencing a nil result. section 2.3.1
  • A failure should stop only the calling test; other tests continue independently. section 2.3

Stop after Parse fails

func TestParse(t *testing.T) { got, err := Parse("https://github.com/inancgumus") if err != nil { t.Fatalf("Parse(%q) err = %q, want <nil>", uri, err) } // Safe to inspect got here. }

Choose Errorf when later checks remain meaningful. In a table-driven test, however, Fatalf stops the whole test function and skips every remaining case. section 2.3.1 section 2.4.4

How Go by Example covers it

How deep it goes
Explains failure scope, safety rationale, and table-driven consequences, but defers implementation internals.
Examples
Uses URL parsing, nil-result protection, URL comparisons, and a data-scheme table case.
What it assumes
Assumes basic Go tests with *testing.T and teaches failure severity through URL parsing examples.
What you can do after
Diagnose test failures and choose Fatalf or Errorf according to whether subsequent checks remain valid.
How it connects
Connects Fatalf with testing.T, Errorf, table-driven testing, 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.