What Tests Are

A test's job is to capture behavior so any future change that breaks it gets caught immediately — not by a user in production. Think of tests as a safety net: you change something, tests run, a failure tells you exactly what broke and where.
- Example: an API endpoint should return 200 with user data → you change an auth middleware → test fails → you know before shipping.
- Example: a record should persist in the DB after a form submission → you refactor the service layer → test fails → the bug never reaches production.
- Example: a frontend component expects { name: string } but the API now returns { fullName: string } → test fails → caught before the user sees a broken UI.
Tests are not just about catching bugs — they also document behavior. A well-written test tells the next developer (or future you) exactly what a function is supposed to do without reading the implementation.
Unit tests test one thing in isolation — a single function or method, no real DB, no real network. They are fast, focused, and should make up the majority of your test suite.
- Write unit tests for: pure logic, calculations, transformations, validation rules, error handling.
- Ask: if I break this function, does this test fail? If not, the test isn't testing the right thing.
Integration tests test how multiple parts work together — your code + a real DB, or your code + a real HTTP handler. They are slower and fewer, but catch wiring mistakes unit tests can't.
- Write integration tests for: DB queries actually persisting data, HTTP handlers returning correct responses end-to-end, services talking to each other correctly.
- Don't use integration tests as a substitute for unit tests — they're too slow and too broad to be your first line of defense.
- Integration tests are usually done on a temporary environment.
How to aim your tests: test behavior, not implementation. Ask what should this do?, not how does this do it?
- Good: assert the returned total is correct given these inputs
- Bad: assert that this specific internal function was called with these exact arguments
- If refactoring your code forces you to rewrite your tests, your tests are aimed too low.
Plan your tests around failure scenarios, not just the happy path. For every function ask: what happens when input is invalid? What if the dependency fails? What if the value is empty or zero?
- Happy path: user deposits 10 BTC → balance is 10 BTC.
- Failure path: user withdraws more than balance → error is returned, balance unchanged.
Test coverage is a guide, not a goal. 100% coverage doesn't mean your code is bug-free — it just means every line ran during tests. A poorly written test can execute a line without actually asserting anything meaningful.
- Aim for coverage of behavior, not lines.
How to catch failures effectively:
- Error messages should tell you what was expected vs what was got — vague failures waste time.
- Use t.Fatal when a failure makes all subsequent assertions meaningless (e.g. if parsing failed, don't keep asserting on the result).
- Use t.Errorf when you want to report a failure but still finish running the rest of the test.
The testing lifecycle in a project:
- Write the test before or alongside the code (TDD) — this forces you to think about the interface before the implementation.
- Unit tests run on every save or commit — they must be fast.
- Integration tests run on CI before merging — slower is acceptable here.
- Never ship code that has failing tests — a failing test is a known bug you chose to ignore.

Golang's Testing

Go's built-in support for unit testing makes it easier to test as you go, check it out.
- Check this article to see testing examples in Go.
Test Driven Development (TDD) discipline: Write a failing test, make the compiler pass, run the test, write enough code to make the test pass, refactor.
In Go, test functions must start with Test followed by a capitalized name (like TestHello) and take a single parameter of type testing.T which provides methods for reporting test failures and logging.
- The Go testing framework automatically handles dependencies between files in the same package. When you run go test, it compiles all .go files in the package (package main for example) and links them together into a single test binary. So if you have hello_test.go and hello.go part of the same package, they are linked and can access each other's functions.
- Test files need to be with a name like xxx_test.go, the test function must start with the word Test, and test function takes one argument only t *testing.T.
Subtests allow you to group and run related test cases (using t.Run for example).
- A benefit of this approach is you can set up shared code that can be used in the other tests.
```
t.Run("saying hello to people", func(t *testing.T) {
	got := Hello("Chris")
	want := "Hello, Chris"

	if got != want {
		t.Errorf("got %q want %q", got, want)
	}
})
```
t.Helper() marks a function as a test helper. When a test fails, the error message will point to the line in the test function rather than inside the helper function, making debugging easier.
Test Driven Development (TDD) loop:
- Write test (define behavior).
- Run -> fail.
- Write minimal code.
- Run -> pass.
- Refactor safely.
- Repeat.
It should not be a goal to have as many tests as possible, but rather to have as much confidence as possible in your code base. Having too many tests can add more overhead in maintenance. Every test has a cost.