In the last lesson, we added an end-to-end test to check that our application works as expected when handling multiple files.

However, because our code now uses concurrency, the order of operations—specifically when it comes to standard output—is non-deterministic. This means that every time we run the program, the order in which results are printed can change, regardless of the order in which the files were passed in.

Why This Is a Problem

Running the application with:

go run .

...returns different orderings of results from run to run. That’s a bad user experience, so we’re going to fix it.

Updating the End-to-End Test

We’ll start by simplifying our end-to-end test.

Instead of comparing against a map[string]string, we’ll now use a simple string comparison using stdout.String().

We could build the expected string with fmt.Sprintf:

expected := fmt.Sprintf("1 2 4\n1 3 13\n...")

But for multi-line strings, that’s clunky. Instead, we’ll use a raw string literal with backticks:

expected := fmt.Sprintf(`      1       5      24 %s
      1       3      13 %s
      0       0       0 %s
      3       8      37 total
`, fileA.Name(), fileB.Name(), fileC.Name())

Then, in the test:

res := stdout.String()
if expected != res {
    t.Logf("Expected:\n%s\nGot:\n%s", expected, res)
    t.Fail()
}

This is much simpler—and cleaner.

Fixing Raw String Gotchas

If your string starts like this:

expected := fmt.Sprintf(`
      1       5      24 %s
...

It will include a leading newline, which causes mismatches. Make sure the opening backtick is on the same line as the first line of your string.

Flaky Test Behavior

Even though the test passes sometimes, it will fail intermittently:

• Use go clean -testcache to clear the test cache and force a re-run.
• You’ll eventually see that results are printed out-of-order.

This is known as a flaky test—one that fails some of the time due to underlying non-deterministic behavior.

Fixing the Ordering in main.go

To fix the issue, go to main.go.

The root cause: we print results as soon as we receive them from the channel.

Step 1: Collect Results in Order

Create a slice to hold results:

results := make([]FileCountResult, len(fileNames))

Now, instead of printing immediately, iterate later:

for _, res := range results {
    // print res
}

Step 2: Store Results in Order

There are two ways to index the results correctly.

✅ Preferred Method: Add an Index to FileCountResult

Add a new field:

type FileCountResult struct {
    ...
    Index int
}

In countFiles, capture and store the index:

for i, fileName := range fileNames {
    go func(i int, name string) {
        ...
        result.Index = i
        ch <- result
    }(i, fileName)
}

When receiving from the channel:

results[res.Index] = res

🟡 Alternative Method: Use a File Name to Index Map

If you can't modify the result struct (e.g., from a third-party package), create a map:

fileNameIndex := make(map[string]int, len(fileNames))
for i, name := range fileNames {
    fileNameIndex[name] = i
}

Then:

idx, ok := fileNameIndex[res.FileName]
if !ok {
    continue
}
results[idx] = res

Both approaches produce deterministic output.

Confirming the Fix

Run the command repeatedly:

go run .

✅ Output now matches file input order.

This approach also improves error printing when dealing with invalid files. Errors now appear in the order of the input files.

Summary

• We had non-deterministic printing due to concurrency.
• This made our test flaky and output unpredictable.
• We solved this by collecting all results first, and printing them in input order.
• Two strategies:
  • Store the index with the result.
  • Map file names to input indices.

With this fix, our end-to-end tests are now deterministic and reliable.

Next up: we’ll add the final end-to-end test to check that CLI flags work correctly to toggle words, lines, and bytes.

See you there!