yoklainterview sim
ProgressHistory

Backend Go Testing Tooling Interview Questions

75 verified Backend Go Testing Tooling interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Go Testing ToolingDifficulty 1
Which naming rule causes a Go source file to be treated as a test file, compiled only when running go test, and normally excluded from go build?
  • aThe package must be declared as package test.
  • bThe filename must end with _test.go.✓
  • cThe filename must start with test_.
  • dThe file must use a .test extension instead of .go.
Explanation:go build ignores any file whose name ends in _test.go; go test compiles those files separately into a test binary. The package name and any filename prefix don't affect this rule.
Go Testing ToolingDifficulty 2
package calc

import "testing"

func TestSum(t testing.T) {
    if Sum(2, 3) != 5 {
        t.Error("wrong sum")
    }
}

What happens when go test is run on this file?
  • aIt fails to compile.
  • bIt runs and reports PASS or FAIL like any other test.
  • cgo test rewrites the signature automatically before compiling.
  • dIt compiles, but go test never runs it as a test.✓
Explanation:go test only invokes functions whose signature is exactly func TestXxx(t testing.T). Here t is testing.T by value, not testing.T. The function still compiles — Go can auto-address a local variable to call a pointer-receiver method like t.Error — but the test runner doesn't recognize this signature as a test, so it's silently skipped. go vet typically flags this as a malformed test signature.
Go Testing ToolingDifficulty 1
What is the key difference between calling t.Error(...) and t.Fatal(...) inside a test function?
  • at.Error fails the test and continues; t.Fatal fails it and stops the goroutine.✓
  • bt.Fatal fails the test and lets it continue; t.Error stops the goroutine immediately.
  • ct.Fatal can only be called from TestMain, never from a TestXxx function.
  • dThey behave identically, except t.Fatal also prints a stack trace.
Explanation:t.Error (log + mark failed) returns control to the caller, so following statements still run. t.Fatal marks the test failed and calls runtime.Goexit, stopping that goroutine's execution — statements after t.Fatal in the same function never run, though registered t.Cleanup functions still fire.
Go Testing ToolingDifficulty 2
func TestAdd(t *testing.T) {
    cases := []struct {
        name       string
        a, b, want int
    }{
        {"positive", 2, 3, 5},
        {"negative", -1, -1, -2},
    }
    for _, c := range cases {
        t.Run(c.name, func(t *testing.T) {
            if Add(c.a, c.b) != c.want {
                t.Errorf("Add(%d,%d): want %d", c.a, c.b, c.want)
            }
        })
    }
}

Compared to looping over cases without t.Run, what does wrapping each case in t.Run(c.name, ...) give you?
  • aThe loop is automatically parallelized across CPU cores.
  • bIt's required syntactically; a table-driven test won't compile without it.
  • cEach case gets its own named result, selectable via -run.✓
  • dThe cases run in a randomized order each time.
Explanation:t.Run creates a subtest with its own name (TestAdd/positive, TestAdd/negative) and its own pass/fail status, shown separately with -v and selectable through -run TestAdd/negative. It doesn't parallelize anything by itself — that requires calling t.Parallel() inside the subtest body.
Go Testing ToolingDifficulty 2
Given a subtest created as t.Run("negative", ...) inside TestAdd, which command runs only that one subtest?
  • ago test -run TestAdd -sub negative
  • bgo test -run TestAdd/negative✓
  • cgo test -subtest negative
  • dgo test TestAdd/negative
Explanation:-run takes a regular expression matched against the slash-separated path of test and subtest names, so TestAdd/negative selects only that subtest. -sub and -subtest aren't real go test flags, and test names aren't passed as bare positional arguments.
Go Testing ToolingDifficulty 3
Inside a subtest created with t.Run, the very first line is t.Parallel(). What does that call actually do?
  • aIt marks the subtest to run alongside parallel siblings, after serial ones finish.✓
  • bIt spawns the subtest onto a separate OS thread outside the normal test scheduler.
  • cIt's a no-op unless go test is also given an explicit -parallel flag.
  • dIt disables t.Error and t.Fatal for that subtest.
Explanation:t.Parallel() signals the test runner that this subtest may run alongside its parallel siblings once the parent function has finished running its non-parallel (serial) subtests. t.Error/t.Fatal still work normally inside a parallel subtest; go test -parallel only controls the maximum concurrency, not whether t.Parallel() takes effect at all.

By specialization

C#/.NET 450Go 450Java 450Node.js 450PHP 450Python 450

By seniority

Backend JuniorBackend MidBackend Senior

Other fields

FrontendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 3300-question Backend bank.

Start interview