t.Error and t.Fatal

Learn t.Error and t.Fatal to report failures.

t.Error and t.Fatal

t.Error / t.Errorf mark the test as failed but keep running, so several failures show up in the same test. t.Fatal / t.Fatalf mark it failed and stop the test immediately.

f, err := os.Open("veri.txt")
if err != nil {
    t.Fatalf("açılamadı: %v", err)  // no point continuing
}
if got := satirSay(f); got != 3 {
    t.Errorf("satır = %d, beklenen 3", got)
}

A good failure message

Go convention: what was called, what came back, what was expected — the "got/want" format:

t.Errorf("Parse(%q) = %v, want %v", girdi, got, want)

Fatal must not be called inside a goroutine; it only works in the goroutine running the test (because it uses runtime.Goexit). Pass errors from goroutines back to the main test with a channel.

Exercise got/want message

Pretend you forgot to implement Buyut(s string) string: it returns s unchanged. For got := Buyut("go") and want := "GO", print the message fmt.Printf("Buyut(%q) = %q, want %q\n", ...).

Show example solution

package main

import "fmt"

func Buyut(s string) string { return s }

func main() {
    got, want := Buyut("go"), "GO"
    if got != want {
        fmt.Printf("Buyut(%q) = %q, want %q\n", "go", got, want)
    }
}

Test yourself

When is t.Fatal preferred?
- When later steps depend on the previous result (e.g. the file failed to open)
- Always
- Never
- Only in benchmarks
Show answer

When later steps depend on the previous result (e.g. the file failed to open) — Use Fatal when continuing would cause a nil pointer error or meaningless extra failures; for independent checks Error is enough.

Stop the test

if err != nil {
    t.____("kurulum başarısız: %v", err)
}

Show answer

if err != nil {
    t.Fatalf("kurulum başarısız: %v", err)
}

Method and behavior

t.Error

Fail, continue
t.Fatal

Fail, stop
t.Log

Just a note
t.Skip

Skip the test

Next lesson: Table-driven tests

We Are Enhancing Your Experience

Cookie Preferences

Strictly Necessary Cookies

Analytical Cookies