writing-good-tests

# Writing Good Tests

## Philosophy

**"Write tests. Not too many. Mostly integration."** — Kent C. Dodds

Tests verify real behavior, not implementation details. The goal is confidence that your code works. Coverage numbers are neccessary but not sufficient.

**Core principles:**

1. Test behavior, not implementation — refactoring shouldn't break tests
2. Integration tests provide better confidence-to-cost ratio than unit tests
3. Wait for actual conditions, not arbitrary timeouts
4. Mock strategically — real dependencies when feasible, mocks for external systems
5. NEVER pollute production code with test-only methods

## Test Structure

Always prefer and use table driven tests, with a single test function that is then given a name, fed an input, and then asserts output and error return equality.

Once this is implemented, test cases should be cheap and easy to add. Ensure there are cases for all possible success and error cases. If possible exhaustively test for all side effects. If a side effect is contained within the function that is being tested and not part of the return, but has a material effect on how the function behaves consider mocking. This could also be a potential bad code smell, and a refactor of the function to make it more testable should be considered.

```go
package foo

import (
	"errors"
	"fmt"
	"testing"
)

var (
	ErrEmpty      = errors.New("empty")
	ErrNotInt     = errors.New("not an int")
	ErrOutOfRange = errors.New("out of range")
)

func TestParsePort(t *testing.T) {
	t.Parallel()

	type tc struct {
		name string
		in   string
		want int
		err  error
	}

	tests := []tc{
		{
			name: "valid_low",
			in:   "1",
			want: 1,
		},
		{
			name: "valid_high",
			in:   "65535",
			want: 65535,
		},
		{
			name: "empty",
			in:   "",
			err:  ErrEmpty,
		},
		{
			name: "not_int",
			in:   "abc",
			err:  ErrNotInt,
		},
		{
			name: "out_of_range_zero",
			in:   "0",
			err:  ErrOutOfRange,
		},
		{
			name: "out_of_range_too_big",
			in:   "7000