Pengujian otomatis, bukti bahwa kode Anda melakukan yang Anda kira.

Alasan jujur menulis tes otomatis bukan "kebenaran" secara abstrak, melainkan kepercayaan diri untuk mengubah kode tanpa rasa takut. Sistem tanpa tes mengapur: setiap edit berisiko memecah sesuatu yang tak terlihat, jadi orang berhenti refactor, berhenti upgrade dependensi, dan memutar mengelilingi bagian yang menakutkan. Sistem yang teruji baik tetap lunak, Anda bisa menyusun ulang secara agresif karena suite tes hijau memberi tahu Anda, dalam hitungan detik, bahwa perilaku tetap berlaku. Tes lah yang membuat codebase terus berevolusi alih-alih membusuk.

Tes juga spesifikasi yang bisa dieksekusi. Dokumen prosa menyimpang dari kenyataan (masalah yang sama yang dicatat bab gRPC soal kontrak REST); tes yang menegaskan Divide(10, 2) == 5 tidak bisa bohong, ia entah lulus terhadap kode saat ini atau tidak. Baca suite tes yang baik dan Anda mempelajari persis apa yang dijanjikan kode, dengan contoh. Dan tes adalah jaring regresi: begitu Anda menulis tes untuk sebuah bug, bug itu tidak akan pernah diam-diam kembali, jaring menangkapnya di setiap run masa depan.

Tidak semua tes setara, dan keputusan strategis terpenting campurannya. Piramida pengujian heuristik pemandu: punya banyak tes unit cepat murah di dasar, lebih sedikit tes integrasi di tengah, dan sangat sedikit tes end-to-end lambat mahal di puncak. Bentuknya berasal dari kompromi yang mengalir di seluruh manual ini: saat Anda naik, tes makin realistis (ia menggerakkan lebih banyak sistem nyata) tapi juga lebih lambat, lebih rapuh, dan lebih sulit di-debug.

Setiap tes yang baik, di setiap lapisan, punya struktur tiga ketukan yang sama, Arrange, Act, Assert (AAA; dunia BDD menyebutnya Given-When-Then). Arrange menyiapkan dunia dan input; Act melakukan satu operasi yang diuji; Assert memeriksa hasilnya sesuai harapan. Menjaga fase-fase ini terpisah dan menguji satu perilaku per tes membuat kegagalan langsung terbaca: Anda tahu persis perilaku mana yang rusak.

// File naming convention: foo.go is tested by foo_test.go in the same package.
// Test functions are func TestXxx(t *testing.T), the `go test` tool finds them.
func TestDiscount_AppliesPercentage(t *testing.T) {
    // Arrange, set up inputs (and any doubles)
    cart := Cart{Subtotal: 200}
    coupon := Coupon{Percent: 10}

    // Act, the ONE operation under test
    total := ApplyDiscount(cart, coupon)

    // Assert, state the expectation; a good message explains the failure
    if total != 180 {
        t.Errorf("ApplyDiscount(200, 10%%) = %d; want 180", total)
    }
}

# pytest discovers files named test_*.py and functions named test_*.
# A bare `assert` is enough, pytest rewrites it to show a rich failure diff.
def test_discount_applies_percentage():
    # Arrange, set up inputs (and any doubles)
    cart = Cart(subtotal=200)
    coupon = Coupon(percent=10)

    # Act, the ONE operation under test
    total = apply_discount(cart, coupon)

    # Assert, pytest prints actual vs expected automatically on failure
    assert total == 180

Apa yang membuat assertion baik

• Uji perilaku, bukan implementasi. Tegaskan hasil yang teramati (diskon diterapkan), bukan mekanik internal (helper privat ini dipanggil). Tes yang terkopel implementasi pecah di setiap refactor dan mengalahkan seluruh tujuannya (bagian 1, bagian 20).
• Satu alasan gagal. Tes yang menegaskan lima hal tak berhubungan memberi tahu sedikit saat ia merah. Prefer tes terfokus dengan nama deskriptif, namanya harus terbaca seperti kalimat tentang perilakunya.
• Deterministik. Input sama, hasil sama, setiap run, urutan apa pun, sifat yang dilindungi bagian 14.

Unit test memverifikasi satu potongan logika kecil, fungsi atau method, terisolasi dari sisa sistem. Tanpa database, tanpa jaringan, tanpa file system, tanpa jam: hanya input masuk, output diperiksa. Isolasi itulah yang membuatnya cepat (ribuan berjalan dalam detik) dan presisi (kegagalan menunjuk tepat satu unit). Mereka dasar piramida yang lebar (bagian 2) dan tempat sebagian besar coverage kasus tepi dan cabang Anda harus tinggal.

Target alami tes unit adalah logika domain/bisnis Anda: kalkulasi dan keputusan murni yang secara inheren tidak butuh I/O: aturan harga, validasi, transisi state, parsing. (Ini memetakan langsung ke lapisan service dari bab controllers-services-repositories; mendorong logika ke fungsi murni di sana persis yang membuatnya bisa di-unit-test di sini.)

// The unit: pure logic, no I/O, trivially testable.
func IsStrongPassword(p string) bool {
    if len(p) < 8 { return false }
    var hasDigit, hasUpper bool
    for _, r := range p {
        if r >= '0' && r <= '9' { hasDigit = true }
        if r >= 'A' && r <= 'Z' { hasUpper = true }
    }
    return hasDigit && hasUpper
}

func TestIsStrongPassword(t *testing.T) {
    if IsStrongPassword("short1A") {            // 7 chars -> too short
        t.Error("expected short password to be rejected")
    }
    if !IsStrongPassword("longEnough9") {        // meets all rules
        t.Error("expected valid password to be accepted")
    }
}

// Run:  go test ./...        (-v for verbose, -run TestIsStrong to filter)

# The unit: pure logic, no I/O, trivially testable.
def is_strong_password(p: str) -> bool:
    if len(p) < 8:
        return False
    return any(c.isdigit() for c in p) and any(c.isupper() for c in p)

def test_rejects_short_password():
    assert is_strong_password("short1A") is False    # 7 chars -> too short

def test_accepts_valid_password():
    assert is_strong_password("longEnough9") is True  # meets all rules

# Run:  pytest            (-v verbose, -k strong to filter by name)

Unit nyata bergantung pada hal lain, repository, payment gateway, pengirim email. Untuk menguji unit dalam isolasi Anda mengganti kolaborator itu dengan test double: pengganti yang Anda kendalikan. "Mock" dipakai longgar dalam percakapan, tapi kosakata presisi (dari Gerard Meszaros / Martin Fowler) membedakan lima jenis, dan mengetahui perbedaannya mempertajam cara Anda menguji.

Verifikasi state vs verifikasi interaksi

Perbedaan terdalam: stub/fake mendukung verifikasi state (Anda menegaskan hasilnya), sementara mock/spy mendukung verifikasi interaksi (Anda menegaskan panggilan terjadi). Prefer verifikasi state, ia kokoh terhadap refactoring. Rengkuh verifikasi interaksi hanya saat interaksi adalah perilakunya (email benar-benar harus dikirim, tagihan harus diterbitkan tepat sekali). Over-mocking interaksi penyebab utama tes rapuh (bagian 20).

// The unit depends on an interface, the seam that lets us substitute a double (sec 6).
type UserRepo interface{ FindByID(id string) (*User, error) }

type Notifier interface{ Send(to, msg string) error }

func Greet(repo UserRepo, n Notifier, id string) error {
    u, err := repo.FindByID(id)        // collaborator 1
    if err != nil { return err }
    return n.Send(u.Email, "Hi "+u.Name) // collaborator 2 (interaction we care about)
}

// STUB: returns a canned user. SPY: also records what Send received.
type stubRepo struct{ user *User }
func (s stubRepo) FindByID(string) (*User, error) { return s.user, nil }

type spyNotifier struct{ calls int; lastTo string }
func (s *spyNotifier) Send(to, msg string) error { s.calls++; s.lastTo = to; return nil }

func TestGreet_SendsEmail(t *testing.T) {
    repo := stubRepo{user: &User{Email: "a@x.com", Name: "Ada"}} // arrange (stub)
    spy := &spyNotifier{}

    _ = Greet(repo, spy, "u1")                                   // act

    if spy.calls != 1 || spy.lastTo != "a@x.com" {               // assert the interaction
        t.Errorf("expected one email to a@x.com, got %d to %q", spy.calls, spy.lastTo)
    }
}

from unittest.mock import Mock

# The unit depends on injected collaborators (sec 6).
def greet(repo, notifier, user_id):
    user = repo.find_by_id(user_id)          # collaborator 1
    notifier.send(user.email, f"Hi {user.name}")  # collaborator 2 (the interaction)

def test_greet_sends_email():
    # STUB: a Mock configured to return a canned user
    repo = Mock()
    repo.find_by_id.return_value = User(email="a@x.com", name="Ada")
    notifier = Mock()                        # will record calls (acts as spy/mock)

    greet(repo, notifier, "u1")              # act

    # assert the INTERACTION happened exactly as expected
    notifier.send.assert_called_once_with("a@x.com", "Hi Ada")

Go cenderung menulis double kecil manual terhadap interface (eksplisit, tanpa sihir); unittest.mock Python membuat double fleksibel yang keduanya stub return dan mencatat panggilan. Konsep sama, ergonomi berbeda.

Teknik tunggal yang membuat unit testing mungkin adalah dependency injection (DI): alih-alih unit membuat atau meraih kolaboratornya, ia menerimanya dari luar. Titik serah itu seam: tempat tes bisa menyelipkan double (bagian 5). Tanpa seam, tanpa isolasi. Inilah kenapa arsitektur controllers-services-repositories bersikeras meneruskan dependensi ke bawah: itu bukan seremoni, itulah yang menjaga kode tetap testable.

// Depend on an INTERFACE, not a concrete type, that interface is the seam.
type OrderRepo interface{ Save(o Order) error }

type OrderService struct{ repo OrderRepo } // injected, not constructed inside

func NewOrderService(r OrderRepo) *OrderService { return &OrderService{repo: r} }

func (s *OrderService) Place(o Order) error {
    if o.Total <= 0 { return errors.New("invalid total") } // pure logic, easily tested
    return s.repo.Save(o)
}

// In tests: a FAKE in-memory repo (no real DB needed)
type fakeRepo struct{ saved []Order }
func (f *fakeRepo) Save(o Order) error { f.saved = append(f.saved, o); return nil }

func TestPlace_RejectsInvalidTotal(t *testing.T) {
    svc := NewOrderService(&fakeRepo{})
    if err := svc.Place(Order{Total: 0}); err == nil {
        t.Error("expected error for non-positive total")
    }
}
// In production:  NewOrderService(postgresRepo), same code, real dependency.

# Accept the collaborator as a constructor argument, that parameter is the seam.
class OrderService:
    def __init__(self, repo):        # injected, not created inside
        self.repo = repo

    def place(self, order):
        if order.total <= 0:
            raise ValueError("invalid total")   # pure logic, easily tested
        self.repo.save(order)

# In tests: a FAKE in-memory repo (no real DB needed)
class FakeRepo:
    def __init__(self): self.saved = []
    def save(self, order): self.saved.append(order)

def test_place_rejects_invalid_total():
    svc = OrderService(FakeRepo())
    with pytest.raises(ValueError):
        svc.place(Order(total=0))

# In production:  OrderService(postgres_repo), same code, real dependency.

Kebanyakan logika perlu diperiksa terhadap banyak pasangan input/output, happy path, kasus tepi, batas, kasus error. Copy-paste satu tes per kasus itu noise. Kedua bahasa punya idiom untuk "body tes sama, banyak kasus": table-driven test Go dan parametrize pytest. Di sinilah Anda mendapat coverage murah dan padat atas cabang dan tepi, kuda beban sesungguhnya lapisan unit.

func TestApplyDiscount(t *testing.T) {
    // The TABLE: each row is one case with a name.
    cases := []struct {
        name     string
        subtotal int
        percent  int
        want     int
    }{
        {"ten percent off 200", 200, 10, 180},
        {"zero discount",       100, 0,  100},
        {"full discount",       100, 100, 0},
        {"rounds down",          99, 10,  90}, // boundary/edge case
    }
    for _, c := range cases {
        // t.Run makes each row a named subtest, failures report the case name.
        t.Run(c.name, func(t *testing.T) {
            got := ApplyDiscount(Cart{Subtotal: c.subtotal}, Coupon{Percent: c.percent})
            if got != c.want {
                t.Errorf("got %d, want %d", got, c.want)
            }
        })
    }
}
// `go test -run TestApplyDiscount/rounds_down` runs just one case.

import pytest

# Each tuple is one case; ids give readable names in the output.
@pytest.mark.parametrize(
    "subtotal, percent, expected",
    [
        (200, 10, 180),
        (100, 0,  100),
        (100, 100, 0),
        (99,  10, 90),     # boundary/edge case
    ],
    ids=["ten-off-200", "zero", "full", "rounds-down"],
)
def test_apply_discount(subtotal, percent, expected):
    got = apply_discount(Cart(subtotal=subtotal), Coupon(percent=percent))
    assert got == expected

# `pytest -k rounds-down` runs just one case; each shows up as its own test.

Tes unit membuktikan tiap bagian bekerja sendirian; tes integrasi membuktikan bagian-bagian bekerja bersama, dan yang penting, bahwa mereka berintegrasi benar dengan sistem eksternal nyata yang Anda mock di lapisan unit: database, cache, message broker, layanan lain. Mereka duduk di tengah piramida (bagian 2): lebih lambat dari tes unit karena I/O nyata terlibat, tapi menangkap kategori bug yang secara struktural tidak bisa ditangkap tes unit.

Pertanyaan berulang: bagaimana mendapat database "nyata" dalam tes tanpa bergantung pada server bersama yang dirawat manual? Jawaban modern Testcontainers: library yang menyalakan database sungguhan dalam container Docker sekali pakai (container bab 21) saat tes, memberi Anda connection string-nya, dan merobohkannya setelahnya. Anda menguji terhadap engine aktual (versi Postgres sama dengan prod), terisolasi penuh, tanpa apa pun yang diinstal. Untuk menjaga tes independen satu sama lain, dua taktik standar transaction rollback (bungkus tiap tes dalam transaksi, roll back di akhir) atau truncate tabel antar tes.

// Build tag keeps slow integration tests out of the fast unit run:
//   //go:build integration      -> run with:  go test -tags=integration ./...
func TestUserRepo_SaveAndFind(t *testing.T) {
    ctx := context.Background()

    // Arrange: start a REAL Postgres in a throwaway container (testcontainers-go)
    pg, err := postgres.Run(ctx, "postgres:16",
        postgres.WithDatabase("app"), postgres.WithUsername("u"), postgres.WithPassword("p"))
    if err != nil { t.Fatal(err) }
    t.Cleanup(func() { pg.Terminate(ctx) }) // torn down automatically after the test

    dsn, _ := pg.ConnectionString(ctx, "sslmode=disable")
    db, _ := sql.Open("postgres", dsn)
    runMigrations(t, db)                    // apply the same schema as production

    repo := NewUserRepo(db)

    // Act: exercise the REAL query path
    _ = repo.Save(User{ID: "u1", Email: "a@x.com"})
    got, err := repo.FindByID("u1")

    // Assert: round-trips correctly through actual SQL
    if err != nil || got.Email != "a@x.com" {
        t.Fatalf("round-trip failed: %v / %+v", err, got)
    }
}

import pytest
from testcontainers.postgres import PostgresContainer

# A fixture spins up a REAL Postgres once per module, then tears it down.
@pytest.fixture(scope="module")
def db_url():
    with PostgresContainer("postgres:16") as pg:   # throwaway container
        url = pg.get_connection_url()
        run_migrations(url)                         # same schema as production
        yield url
        # container stopped automatically on exit

@pytest.fixture
def repo(db_url):
    # function-scoped: clean state per test (truncate / rollback)
    r = UserRepo(db_url)
    yield r
    r.truncate_all()                                # keep tests independent (sec 8)

@pytest.mark.integration            # marker: pytest -m integration
def test_save_and_find(repo):
    repo.save(User(id="u1", email="a@x.com"))       # act through REAL SQL
    got = repo.find_by_id("u1")
    assert got.email == "a@x.com"                   # round-trips correctly

Keduanya mengisolasikan tes lambat di balik flag/marker (build tag Go, marker pytest) supaya suite unit milidetik tetap cepat dan tes DB yang lebih berat berjalan saat diminta atau di CI (bagian 19).

Handler Anda (bab HTTP dan REST) target integrasi utama: Anda ingin menembakkan request nyata ke stack routing + handler + serialisasi Anda dan menegaskan respons nyatanya, status code, header, body, tanpa mengikat socket atau menjalankan server lewat jaringan. Kedua ekosistem menyediakan test client dalam proses yang menggerakkan handler langsung: net/http/httptest Go dan TestClient yang dikirim FastAPI/Starlette (dan padanan Flask).

import (
    "net/http"
    "net/http/httptest"
    "strings"
    "testing"
)

func TestCreateUser_Returns201(t *testing.T) {
    handler := NewRouter(deps)  // the REAL router + handlers (deps may use a fake repo sec 6)

    // Arrange: build a request and an in-memory response recorder (no network)
    body := strings.NewReader(`{"email":"a@x.com","name":"Ada"}`)
    req := httptest.NewRequest(http.MethodPost, "/api/v1/users", body)
    req.Header.Set("Content-Type", "application/json")
    rec := httptest.NewRecorder()

    // Act: drive the handler directly
    handler.ServeHTTP(rec, req)

    // Assert: on the real response, status, then body
    if rec.Code != http.StatusCreated {
        t.Fatalf("status = %d; want 201; body=%s", rec.Code, rec.Body.String())
    }
    if ct := rec.Header().Get("Content-Type"); !strings.Contains(ct, "application/json") {
        t.Errorf("content-type = %q", ct)
    }
}

from fastapi.testclient import TestClient
from app import app   # the REAL FastAPI app (dependencies may be overridden with fakes sec 6)

client = TestClient(app)   # drives the app in-process, no network, no running server

def test_create_user_returns_201():
    # Act: fire a real request through routing + handler + serialization
    resp = client.post("/api/v1/users", json={"email": "a@x.com", "name": "Ada"})

    # Assert: on the real response, status, headers, body
    assert resp.status_code == 201
    assert resp.headers["content-type"].startswith("application/json")
    assert resp.json()["email"] == "a@x.com"

# FastAPI tip: override real dependencies with fakes via app.dependency_overrides
# so the handler runs but the repo is in-memory, an integration test of the web layer.

Di dunia microservice (bab gRPC dan desain API), layanan jarang hidup sendiri, ia mengonsumsi yang lain dan dikonsumsi yang lain. Bahayanya: provider mengubah bentuk responsnya, semua tesnya sendiri lulus, tapi diam-diam memecah setiap consumer. Menguji end-to-end setiap kombinasi sangat lambat. Contract testing menyelesaikannya dengan memverifikasi kedua sisi setuju pada antarmukanya, tanpa menjalankannya bersama.

Tool seperti Pact mengimplementasikan ini: tes consumer mencatat request yang ia buat dan respons yang ia harapkan ke file kontrak; CI provider memutar ulang kontrak itu terhadap provider nyata dan gagal jika tidak lagi berlaku. Untuk layanan gRPC/Protobuf, .proto plus deteksi perubahan yang memecah skema (tooling buf dari bab gRPC) memainkan peran serupa, skema adalah kontrak yang diperiksa mesin, dan CI menolak perubahan tak kompatibel.

Tes end-to-end (E2E) menggerakkan sistem yang terakit penuh lewat antarmuka eksternal nyatanya, persis seperti pengguna atau klien, tanpa internal yang di-stub, semuanya berjalan: API, database, cache, layanan dependen. Ia menjawab satu pertanyaan yang tidak bisa dijawab lapisan lebih rendah: apakah semua bagian, dirangkai nyata, benar-benar mengirimkan hasil yang terlihat pengguna? Ia puncak piramida (bagian 2): realisme maksimum, biaya maksimum.

Coverage mengukur berapa banyak kode Anda yang dieksekusi tes, biasanya persentase baris atau cabang yang dijalankan selama suite. Ia berguna sebagai senter untuk menemukan kode yang tidak diuji sama sekali, tapi sangat mudah salah dibaca sebagai ukuran kualitas tes. Ia bukan. Coverage memberi tahu apa yang dieksekusi, tidak pernah apa yang ditegaskan secara bermakna.

# Built into the toolchain, no extra dependency.
go test -cover ./...                       # prints % per package

go test -coverprofile=cover.out ./...      # write a detailed profile
go tool cover -func=cover.out              # per-function breakdown
go tool cover -html=cover.out              # open an annotated, line-by-line HTML view

# Via the coverage.py / pytest-cov plugin.
pip install pytest-cov

pytest --cov=app                           # coverage for the `app` package
pytest --cov=app --cov-report=term-missing # show exactly which lines are UNcovered
pytest --cov=app --cov-report=html         # browsable htmlcov/ report
pytest --cov=app --cov-branch              # branch coverage, not just line

Line vs branch coverage

Line coverage bertanya "apakah baris ini berjalan?" Branch coverage bertanya pertanyaan lebih sulit "apakah setiap arah dari setiap keputusan diambil?" Satu tes bisa memukul 100% baris dari sebuah if sementara hanya pernah mengambil cabang true, jalur else tidak tereksekusi dan tidak teruji meski line coverage tampak lengkap. Branch coverage angka yang lebih jujur; prefer itu.

Tes flaky lulus kadang dan gagal lain kali tanpa perubahan kode apa pun. Flakiness korosif: ia melatih tim mengabaikan build merah ("tinggal jalankan ulang"), dan begitu orang berhenti memercayai suite, suite mati, run hijau tidak lagi berarti apa-apa. Tes flaky boleh dibilang lebih buruk daripada tidak ada tes, karena ia menghabiskan waktu dan mengikis kepercayaan yang memberi nilai bagi tes (bagian 1).

Tes butuh data dan state awal yang dikenal, dan cara Anda membangunnya menentukan apakah suite tetap terbaca atau membusuk jadi setup soup. Dua tool terkait: fixture mengelola setup dan teardown (dunia tempat tes berjalan, koneksi DB, dir temp, klien yang login), dan factory membangun objek tes dengan default masuk akal supaya tiap tes hanya menyatakan field yang benar-benar ia pedulikan.

// Go favors explicit helpers over magic. t.Helper() keeps failure line numbers useful.
// A "factory" with functional options: specify only the fields that matter to the test.
func newUser(t *testing.T, opts ...func(*User)) User {
    t.Helper()
    u := User{ID: "u1", Email: "default@x.com", Active: true} // sensible defaults
    for _, o := range opts { o(&u) }
    return u
}
func withEmail(e string) func(*User) { return func(u *User) { u.Email = e } }

// A "fixture" via t.Cleanup: setup returns the thing + auto-teardown.
func newTempStore(t *testing.T) *Store {
    t.Helper()
    dir := t.TempDir()                 // auto-removed after the test
    s := OpenStore(dir)
    t.Cleanup(func() { s.Close() })    // teardown runs even if the test fails
    return s
}

func TestSignup(t *testing.T) {
    store := newTempStore(t)
    u := newUser(t, withEmail("ada@x.com")) // only the relevant field is stated
    _ = store.Save(u)
    // ...assert...
}

import pytest

# pytest FIXTURES: setup before `yield`, teardown after. Injected by parameter name.
@pytest.fixture
def temp_store(tmp_path):           # tmp_path is a built-in fixture (auto-cleaned dir)
    store = Store(tmp_path)
    yield store                     # the test runs here
    store.close()                   # teardown, runs even if the test fails

# A FACTORY: defaults + overrides, so tests state only what they care about.
def make_user(**overrides):
    return User(**{"id": "u1", "email": "default@x.com", "active": True, **overrides})

def test_signup(temp_store):
    user = make_user(email="ada@x.com")   # only the relevant field is stated
    temp_store.save(user)
    # ...assert...

# Libraries like factory_boy / model_bakery scale this up for complex object graphs.

Test-Driven Development membalik urutan biasa: Anda menulis tes gagal dulu, lalu kode minimum untuk meloloskan, lalu membersihkan, mengulang dalam siklus kecil. Disiplinnya loop tiga ketukan yang terkenal: Red (tulis tes, lihat gagal), Green (buat lulus sesederhana mungkin), Refactor (perbaiki desain sementara tes tetap hijau). Menulis tes dulu memaksa Anda mendefinisikan perilaku yang diinginkan dan antarmuka bersih sebelum Anda terjerat implementasi.

Manfaat nyata TDD orde kedua: ia menghasilkan kode yang testable by construction (Anda tidak bisa menulis unit yang tak teruji jika tesnya datang dulu), ia menjaga Anda fokus pada satu perilaku kecil pada satu waktu, dan langkah "refactor" aman justru karena tes yang barusan Anda tulis menjaganya. Ia teknik desain sekaligus teknik pengujian.

Tiga sumber non-determinisme merusak tes jika dibiarkan nyata, jam, generator acak, dan jaringan, dan mereka tersangka biasa di balik flakiness (bagian 14). Obat untuk ketiganya sama: ubah dependensi tersembunyi menjadi yang disuntikkan (bagian 6) supaya tes mengendalikannya.

Waktu & keacakan: suntikkan keduanya

Kode yang memanggil time.Now() atau random() langsung tidak testable dan flaky, keluarannya berubah tiap run. Jadikan jam dan RNG dependensi yang diterima unit, lalu berikan jam tetap (selalu mengembalikan instan yang sama) atau RNG ber-seed di tes. Sekarang "token kedaluwarsa dalam 1 jam" atau "pilih shard acak" sepenuhnya deterministik dan bisa ditegaskan.

HTTP eksternal: stub batasnya

Jangan pernah memukul API pihak ketiga nyata dalam tes unit/integrasi, ia lambat, flaky, kena rate-limit, dan mungkin punya efek samping. Kedua ekosistem membiarkan Anda mencegat HTTP secara lokal: httptest.Server Go mendirikan server palsu yang Anda arahkan klien Anda; responses/respx Python menambal lapisan HTTP untuk mengembalikan respons siap. (Dan ingat bagian 5: prefer membungkus API di balik interface Anda sendiri supaya kebanyakan tes mock itu, menyisakan stub level HTTP untuk menguji adapter klien itu sendiri.)

// 1) Injected clock, deterministic time.
type Clock interface{ Now() time.Time }
type fixedClock struct{ t time.Time }
func (f fixedClock) Now() time.Time { return f.t }

func TestTokenExpiry(t *testing.T) {
    clk := fixedClock{t: time.Date(2026, 1, 1, 12, 0, 0, 0, time.UTC)} // frozen
    tok := NewToken(clk, time.Hour)
    if tok.ExpiresAt != clk.Now().Add(time.Hour) {
        t.Error("expiry not computed from the injected clock")
    }
}

// 2) Stub an external HTTP API with httptest.Server, no real network.
func TestFetchRate(t *testing.T) {
    srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, _ *http.Request) {
        w.Write([]byte(`{"usd_inr": 83.2}`)) // canned response
    }))
    defer srv.Close()

    client := NewRatesClient(srv.URL) // point the client at the fake server's URL
    rate, _ := client.USDINR()
    if rate != 83.2 { t.Errorf("got %v", rate) }
}

import responses
from datetime import datetime, timezone

# 1) Injected clock, deterministic time (freezegun is a popular alternative).
def test_token_expiry():
    frozen = datetime(2026, 1, 1, 12, 0, tzinfo=timezone.utc)
    tok = make_token(now=lambda: frozen, ttl=3600)  # clock injected as a callable
    assert tok.expires_at == frozen.timestamp() + 3600

# 2) Stub external HTTP with `responses`, patches the HTTP layer, no real network.
@responses.activate
def test_fetch_rate():
    responses.add(
        responses.GET, "https://api.rates.com/usd-inr",
        json={"usd_inr": 83.2}, status=200,           # canned response
    )
    client = RatesClient("https://api.rates.com")
    assert client.usd_inr() == 83.2

Tes fungsional membuktikan kode benar; tes performa membuktikan ia cukup cepat, sumbu yang sepenuhnya berbeda, dan yang sangat penting bagi kekhawatiran scaling bab 18-19. Dua rasa berbeda: benchmark (mikro: seberapa cepat fungsi/endpoint ini?) dan load test (makro: bagaimana seluruh sistem berperilaku di bawah N pengguna serentak?).

// Benchmarks live beside tests; the tool tunes b.N until timing is stable.
func BenchmarkParseEvent(b *testing.B) {
    payload := []byte(`{"type":"click","ts":1717000000}`)
    b.ReportAllocs()                 // also report allocations/op
    for i := 0; i < b.N; i++ {       // the loop the framework times
        _, _ = ParseEvent(payload)
    }
}

// Run:  go test -bench=. -benchmem
//   BenchmarkParseEvent-8   3142051   382 ns/op   96 B/op   2 allocs/op
// Compare runs with `benchstat` to catch performance REGRESSIONS over time.

# pip install pytest-benchmark, the `benchmark` fixture times the callable.
def test_parse_event_perf(benchmark):
    payload = b'{"type":"click","ts":1717000000}'
    result = benchmark(parse_event, payload)   # runs it many times, reports stats
    assert result.type == "click"              # still assert correctness

# Output reports min/mean/median/stddev; --benchmark-compare flags regressions.

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  stages: [
    { duration: '30s', target: 100 },  // ramp up to 100 virtual users
    { duration: '1m',  target: 100 },  // hold
    { duration: '30s', target: 0 },    // ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<300'],  // 95th-percentile latency must stay < 300ms
    http_req_failed:   ['rate<0.01'],  // error rate must stay under 1%
  },
};
export default function () {
  const res = http.get('https://staging.example.com/api/v1/health');
  check(res, { 'status 200': (r) => r.status === 200 });
}
# Run:  k6 run load_test.js, fails the build if a threshold is breached.

Suite tes hanya bernilai jika ia berjalan otomatis, di setiap perubahan, sebagai gerbang. Di sinilah testing bertemu pipeline bab 21 (bagian 19 di sana): di setiap push, CI menjalankan tes, dan kegagalan memblokir merge atau deploy. Inti gradien kecepatan piramida (bagian 2) memberi umpan balik cepat di sini, jalankan tes unit milidetik di setiap commit, tes integrasi/E2E yang lebih berat di tahap yang tepat.

name: tests
on: [push, pull_request]
jobs:
  unit:                          # fast, runs on every push
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: go test -race -cover ./...          # Go: race detector + coverage
      # - run: pytest -m "not integration" --cov  # Python: skip slow tests here

  integration:                   # heavier, real DB via services / testcontainers
    runs-on: ubuntu-latest
    needs: unit                  # only if unit tests passed
    services:
      postgres:
        image: postgres:16
        env: { POSTGRES_PASSWORD: p }
        ports: ["5432:5432"]
    steps:
      - uses: actions/checkout@v4
      - run: go test -tags=integration ./...     # or: pytest -m integration
# A failed job fails the check -> branch protection blocks the merge.

Tes punya biaya, untuk ditulis, dijalankan, dan dirawat saat kode berubah, jadi tujuannya tidak pernah "uji semuanya" melainkan kepercayaan maksimum per unit usaha. Strategi koheren kebanyakan set keputusan penilaian tentang apa yang diuji, di lapisan mana, dan apa yang dibiarkan.

Apa yang diuji berat

• Logika & aturan bisnis: harga, validasi, state machine, apa pun dengan cabang dan kasus tepi. Tes unit murah cepat; pembayaran tertinggi (bagian 4, bagian 7).
• Bug yang pernah Anda perbaiki: setiap perbaikan dapat tes regresi supaya tidak kembali (bagian 1).
• Jalur kritis & uang: auth, pembayaran, integritas data dapat coverage di banyak lapisan, termasuk E2E tipis (bagian 12).
• Seam integrasi: query Anda, serialisasi, dan kontrak antar layanan (bagian 8-11), tempat bug halus bersembunyi.

Apa yang diuji ringan atau tidak sama sekali

• Kode sepele: getter polos, lem framework, kode hasil generasi. Mengujinya usaha tanpa wawasan.
• Library pihak ketiga: asumsikan bekerja; uji pemakaian Anda terhadapnya, bukan internalnya (bagian 5).
• Detail implementasi: helper privat dan urutan panggilan persis. Uji perilaku teramati supaya refactor tidak memicu kegagalan palsu.

Seluruh manual dipadatkan menjadi yang Anda raih saat tertekan.