So far throughout this course, we've been using black box testing for our unit tests.

---

What Is Black Box Testing?

In Go, black box tests:

• Only test exported (public) functions, methods, types, etc.
• Use the _test suffix in the package name of the test file.

Example:

package display_test // black box test

This means the test file only has access to the public API of the package.

---

What Is White Box Testing?

Go also supports white box testing:

• White box tests are written without the _test suffix.
• These tests have full access to unexported/internal code.

Example:

package display // white box test

To clarify:

• Black box = external test (consumer perspective)
• White box = internal test (developer perspective)

---

Why Prefer Black Box Testing?

By default, I prefer black box testing because:

• You use your code like a real consumer would.
• It reduces test brittleness.
• Refactors are less likely to break your tests.

---

Example: External vs Internal Tests

In the repo:

• display_external_test.go uses the public API (black box)
• display_internal_test.go accesses internals directly (white box)

Both tests currently pass:

go test ./display

---

Refactoring Internals

Suppose we refactor the display package to remove the embedded args struct and set the internal fields directly again:

type Options struct {
    showBytes bool
    showWords bool
    showLines bool
}

In NewOptions, we now directly assign:

return Options{
    showBytes: args.ShowBytes,
    showWords: args.ShowWords,
    showLines: args.ShowLines,
}

Running tests again:

go test ./display

✅ Black box tests pass
❌ White box tests fail

Why? Because white box tests accessed internals directly, which we just changed.

---

Why This Matters

• Black box tests: Still work — we didn’t change the public API.
• White box tests: Broke — they relied on internal implementation details.

This demonstrates why black box tests are more resilient to refactoring.

---

When White Box Tests Make Sense

Now let’s look at counter/count.go. This struct had exported fields:

type Counts struct {
    Bytes int
    Words int
    Lines int
}

We’re only using these fields inside the counter package. The public API just exposes methods like:

• Count(r io.Reader) Counts
• Add(c Counts)
• Print(w io.Writer)

No one outside needs to access Bytes, Words, or Lines directly.

Refactor: Make Fields Unexported

We change the struct:

type Counts struct {
    bytes int
    words int
    lines int
}

Everything still works when we build and run:

go build ./cmd
./cmd/wordcount words.txt

But now, the black box tests for counter fail:

go test ./counter
# 36 errors accessing unexported fields

---

Fixing the Tests

We could:

1. Write accessor methods like GetWords(), GetLines(), etc.
2. Or convert the test into a white box test

We choose white box testing, since:

• These fields aren’t part of the public API.
• We don’t want to add unnecessary getters.

Update count_test.go:

• Remove _test suffix from the package name
• Remove counter. import prefix

Now the test has access to internal fields and compiles again.

go test ./counter
# ✅ all tests pass

---

Summary: When to Use Which

Testing Style	Use When...
Black Box	Default. Good for testing public interfaces. More robust to refactors.
White Box	You need access to internals, e.g. validating internal state or logic, or testing unexported fields.

Remember:
✅ Tests should make it easier to work on code — not harder.
Use whichever approach enables speed without sacrificing correctness.

---

Final Changes and Commit

• Keep display_external_test.go
• Delete display_internal_test.go
• Refactored counter tests to white box style

Commit:

git add .
git commit -m "Added tests for display and changed count tests to white box"

---

With that, we’ve finished this module.

In the next one, we’ll explore advanced Go features like concurrency and data streams.