Skip to content
academia.sh
tr
Log in

Course Advanced

Production Go: Testing, Tooling and Performance

Published

By the end of this course

Start course

01

Testing and Measurement

Setting up test functions and helpers with the language's own package, raising coverage with a case list, server-side and client-side test helpers, faking resting on interface separation, only one of a benchmark's two numbers being reproducible, and what coverage data does and does not say.

  1. 01 Test Package Basics The same test file states how many test functions the source contains by counting the text, but states the test's verdict only by running it: against a correct source both tests pass, against a broken source the verdict reverses while the test count stays the same. The limiting measurement runs a test function that carries no assertion and shows that it passes in exactly the same way.
  2. 02 Table-Driven Tests A five-case table's case count is counted from the source, and the number of running subtests is read only by running go test -v — the two match at 5. The limiting measurement shows that adding a sixth case that runs the same lines as an existing one leaves the coverage ratio unchanged at 100.0%.
  3. 03 HTTP Tests The same handler is tested with three requests without ever opening a real port: an existing item returns 200, a nonexistent one 404, a request without a parameter 400 — all three run information learned only by calling handler.ServeHTTP. The limiting measurement reads that the request's address is a fixed address RFC 5737 reserves for documentation purposes, showing that the test exercises the handler, not the network.
  4. 04 Faking and Interface Separation The same ReduceStock body is run with both a recording and a spy Notifier implementation: in a normal reduction both give the same verdict, and the spy object's call count reads 1. The limiting measurement shows that in a call reducing more than the stock, the real implementation rejects the negative remainder while the spy object silently records the same call.
  5. 05 Benchmarking Eleven pieces of information are gathered about one program and split among three tellers — 2 by the source, 5 by a tool with no run needed, 4 only by running it. The benchmark tool produces one of these four run pieces of information: the allocation count of two writings of the same work gives the same value across five runs; the limiting measurement shows that even this number cannot be compared without saying what it counts.
  6. 06 Coverage Reporting The same function tested with three separate test sets gives three separate coverage ratios — 57.1%, 85.7%, 100.0% — and the uncovered block count drops correspondingly to 3, 1, and 0. The limiting measurement shows, by running the third set — the one that gives 100% coverage — against a broken source, that it catches no real defect at all in a branch whose return value it never checks.

02

Performance and Memory

What number the profile data carries, the compiler reporting in a readable form its decision on whether to allocate a value on the stack or the heap, the effect of allocation pressure on garbage collection behavior, and resolving execution traces by event count.

  1. 01 Profiling A profile is a run fact and in this lesson it is read as a number: how many values the same function's two call forms allocate. Limiting measurement: a profile sees only the path that runs — the values a branch that never executes would have allocated never appear in the profile, even if they sit written in the source.
  2. 02 Escape Analysis Escape analysis is a tool fact: the compiler decides whether to allocate a value on the stack or the heap and reports this without a run. Three of four functions move to the heap, and the same function changes this decision with a small change. Limiting measurement: this decision is not a promise of the language, it is an implementation detail tied to the compiler's version.
  3. 03 Garbage Collection Behavior The reduction of allocation pressure is measured with a number: preallocation, buffer reuse, and the choice between value and pointer carry the same work's allocation count from four to one, from four to zero, from one to sixty-five. Limiting measurement: a number going down is not always an improvement — a style that harms readability can reach the same number too.
  4. 04 Tracing An execution trace is a run fact and here it is read as an event count: two setups processing the same six records, one sequential and one distributed across three workers, produce the same number of record processing events but a different number of worker start events. Limiting measurement: collecting a trace changes the program's behavior, so the numbers are read with that in mind.

03

Building and Distribution

Which of a directory's files enters the build determined by a build tag, a single command producing output for another platform, a version string embedded into the binary through a linker option, the compatibility promise a module publish carries, what a static analyzer finds and does not find in a known-defect scan, and the cost of calling a native library.

  1. 01 Build Tags Which of six source files in the same directory enters the build is learned not from a running program but from asking the tool; the file count across four tag scenarios is read this way. The limiting measurement shows, by running it, that a file left out by its tag is not deleted from disk but that no tool ever examines it — a flaw in the file becomes visible only once the tag is activated.
  2. 02 Cross-Compilation It is measured whether the same portable source compiles for three separate targets with a single command, with none of those targets installed; compilability here too is a tool fact that requires no run. A second measurement shows that a platform-dependent call's compilability changes across the same three targets. The limiting measurement shows, by modeling, that being compiled does not mean it will run on the target — that an assumption carrying the same name can hold for one target family and fail for another.
  3. 03 Linker Options It is measured that a string value written nowhere in the source gets embedded into the binary in three separate forms across three separate build calls; the source text stays character-for-character identical across all three. The limiting measurement shows, by running it, that the embedded value is never validated by the linker — that an unformatted string is accepted just as silently — and that a separate linker option removing the symbol table does not change the program's output.
  4. 04 Module Publishing A version number is declared openly in the source, but the compatibility promise that version carries is checked not by the source itself but by a tool: the signatures of exported functions are compared, counting the names added, changed, and removed. The static verdict is confirmed by genuinely compiling the same source. The limiting measurement shows, by running it, that the promise rests on signatures — that two implementations carrying the identical signature can give a completely different result, and the tool never sees this at all.
  5. 05 Static Analysis and Security Scanning Of the same two sources, one is clean, the other flawed; the compiler accepts both the same way, but an analyzer reports the difference between them through an exit code. Of three patterns, the compiler catches none, the analyzer catches two. The limiting measurement shows, by running it, that coming out clean from analysis does not mean flawless — the third, uncaught pattern genuinely crashes when run. A final measurement compares a dependency's declared version against a modeled threshold list.
  6. 06 C Interoperability The same task is compared in two forms — the language's own code and a C function called through cgo — and both give the same allocation count (1). The package with the native call does not compile with CGO_ENABLED=0, does not cross-compile, and escape analysis makes no statement about the C function's body (0/21 lines). Limiting measurement: memory not freed on the C side shows up in neither the analyzer nor the allocation count — the cost is not in the call itself, but in what the tool can say. The course, and the M09 Go curriculum, close with this lesson through a sixteen-row table.

Final exam

Production Go: Testing, Tooling and Performance — Final Exam

In preparation

This course's question bank is not complete yet. The exam opens here automatically once enough questions are added.

Start typing to search.

↑↓ ↵ Esc navigate · open · close