Learn Go with Tests 验收测试入门用黑盒测试守护 HTTP 服务器的优雅停机【免费下载链接】learn-go-with-testsLearn Go with test-driven development项目地址: https://gitcode.com/gh_mirrors/le/learn-go-with-tests本指南来自开源仓库 Learn Go with Tests 的Testing fundamentals章节核心围绕 intro-to-acceptance-tests.md 展开以HTTP 服务在 Kubernetes 下优雅停机这一真实生产问题为切入点系统讲解什么是验收测试Acceptance Tests、它和单元测试的边界以及如何用 Go 标准库自带的能力编写真正端到端的黑盒测试。读完本文你将掌握基于os/signal、net/http构建优雅停机服务的方法并能够独立编写构建真实程序 → 启动 → 发请求 → 发送 SIGTERM → 验证行为的完整验收测试流程。场景驱动为什么需要优雅停机文中以$WORK作者所在团队的真实经历为背景他们的服务运行在 KubernetesK8s集群上团队以 DORA 指标 为标准追求每天多次向生产环境部署小而增量的改动。K8s 在需要终止一个 Pod实践上就是我们的软件进程时会触发一套终止生命周期termination lifecycle其中关键的一步是向软件发送SIGTERM信号语义相当于你需要自行关闭自己把正在做的工作收尾因为过了某个宽限期grace period之后我会发送SIGKILL到那时就是熄灯走人了。SIGKILL一旦发出程序正在进行的任何工作都会被立即中断。没有优雅停机的代价如果忽视SIGTERM取决于软件的性质可能引发各种问题。作者团队遇到的具体问题是in-flight HTTP 请求当自动化测试正在请求 API 时如果 K8s 决定停止 Pod服务器进程瞬间死亡测试收不到响应直接失败失败触发事故频道的告警迫使开发者停下手中工作去处理这类间歇性失败是对团队的持续骚扰。这种问题并不只存在于测试场景。真实用户向系统发送请求进程在请求处理途中被终止用户大概率会收到一个 5xx 错误——这显然不是想提供的用户体验。而优雅停机要做的正是停止接收新的请求关闭 listener允许所有 in-flight 请求跑完然后再终止进程。优雅停机的标准库实现Server.Shutdown os/signal.NotifyGo 标准库已经为这个需求提供了现成机制无需引入任何第三方依赖net/http/Server.Shutdown优雅地关闭服务器而不中断任何活跃连接。其工作机制是先关闭所有打开的 listeners再关闭所有空闲连接然后无限期等待连接回到空闲状态并关闭如果传入的 context 在关闭完成前过期则返回该 context 的错误否则返回关闭底层 Listener 时产生的错误。这意味着我们完全可以控制宽限期的上限——通过 context 超时。os/signal.Notify把收到的系统信号如SIGTERM转发到我们提供的 channel 上从而让我们可以在收到信号时执行自定义逻辑。两者结合就能实现监听SIGTERM→ 优雅关闭。graceful shutdown 包一个装饰器模式的设计为了让这段逻辑可复用作者编写了github.com/quii/go-graceful-shutdown库它向*http.Server提供一个装饰器函数Decorator pattern在检测到SIGTERM时自动调用其Shutdown方法。典型用法如下func main() { var ( ctx context.Background() httpServer http.Server{Addr: :8080, Handler: http.HandlerFunc(acceptancetests.SlowHandler)} server gracefulshutdown.NewServer(httpServer) ) if err : server.ListenAndServe(ctx); err ! nil { // this will typically happen if our responses arent written before the ctx deadline, not much can be done log.Fatalf(uh oh, didnt shutdown gracefully, some responses may have been lost %v, err) } // hopefully, youll always see this instead log.Println(shutdown gracefully! all responses were sent) }结构非常直白创建一个net/http.Server监听:8080用库包装它再用包装后的实例调用ListenAndServe。这里的SlowHandler内部带有一个time.Sleep来延迟响应——这正是为了给人工测试留出发送SIGTERM的时间窗口。注意ListenAndServe返回错误时通常意味着响应没有在 context 截止时间前写完而打印 shutdown gracefully! all responses were sent 则是我们希望永远看到的日志。单元测试的盲区与手动测试的痛点在编写gracefulshutdown包时作者写了单元测试来证明行为正确并获得了激进重构的信心。但仍然不敢说它真的能工作。于是他们加了一个cmd包把库编译成一个真实程序手动启动它、发一个 HTTP 请求、然后发送SIGTERM观察现象。作者明确指出工程师的直觉应该对这种手动测试感到不适。手动测试无聊不可扩展不准确浪费人力。如果你打算分享一个包同时又想让它保持简单、廉价地演进手动测试是撑不住的。这正是引入验收测试的契机。什么是验收测试本书其他章节大多在讲单元测试它擅长支撑无畏重构、驱动良好的模块化设计、防止回归、提供快速反馈。但单元测试天然只覆盖系统的局部单靠它往往不足以构成有效的测试策略。我们想让系统始终处于可发布状态又不能依赖手动测试于是需要另一种测试验收测试。黑盒测试的本质验收测试是一种黑盒测试black-box test有时也被称为功能测试functional test。它应该像系统用户那样去使用系统测试代码无法访问系统内部实现只能使用系统的公开接口它只能对整个系统做断言观察的是对外表现出的行为正因为如此测试无法使用让测试通过但不证明问题被解决的特殊旁路手段。这与单元测试文件应放在独立测试包中例如package mypkg_test而非package mypkg的原则一脉相承——测试代码与被测对象之间保持距离反而更可信。收益通过时你确知整个系统的行为符合预期比手动测试更准确、更快、更省力写得好时它们就是准确、可验证的系统文档不会落入文档与真实行为脱节的陷阱零 mock全部是真实交互。与单元测试相比的代价编写成本高运行时间长依赖系统整体设计失败时通常不给出根因调试困难不反馈系统内部质量——即便内部实现是一坨垃圾验收测试也可能通过由于黑盒特性并非所有场景都适合用它覆盖。因此只依赖验收测试是愚蠢的它会失去单元测试的大量优点一个堆满验收测试的系统通常会在维护成本和交付时间上付出代价。顺带一提Lead Time 与测试金字塔文中的Lead time指从一次 commit 合并到 main 分支到它部署到生产环境的耗时。不同团队从数周甚至数月到几分钟不等作者所在团队遵循 DORA 研究结论希望把 lead time 控制在10 分钟以内。可靠且 lead time 良好的系统需要平衡的测试策略通常用 Test Pyramid测试金字塔 来描述底层大量快速的单元测试上层少量端到端的验收测试。实战如何编写基础的验收测试回到最初的问题包本身完全可以单元测试但单元测试没能带来足够信心。我们需要的是与真实运行程序集成的验证并把之前的手工检查自动化。高层次的测试步骤构建程序运行它并等待它监听在8080端口向服务器发送一个 HTTP 请求在服务器有机会返回响应之前发送SIGTERM观察是否仍然收到了响应。第一步构建并运行被测程序需要一个acceptancetests包来封装构建 启动 清理的仪式性代码。核心导出函数是LaunchTestProgrampackage acceptancetests import ( fmt math/rand net os os/exec path/filepath syscall time ) const ( baseBinName temp-testbinary ) func LaunchTestProgram(port string) (cleanup func(), sendInterrupt func() error, err error) { binName, err : buildBinary() if err ! nil { return nil, nil, err } sendInterrupt, kill, err : runServer(binName, port) cleanup func() { if kill ! nil { kill() } os.Remove(binName) } if err ! nil { cleanup() // even though its not listening correctly, the program could still be running return nil, nil, err } return cleanup, sendInterrupt, nil } func buildBinary() (string, error) { binName : randomString(10) - baseBinName build : exec.Command(go, build, -o, binName) if err : build.Run(); err ! nil { return , fmt.Errorf(cannot build tool %s: %s, binName, err) } return binName, nil } func runServer(binName string, port string) (sendInterrupt func() error, kill func(), err error) { dir, err : os.Getwd() if err ! nil { return nil, nil, err } cmdPath : filepath.Join(dir, binName) cmd : exec.Command(cmdPath) if err : cmd.Start(); err ! nil { return nil, nil, fmt.Errorf(cannot run temp converter: %s, err) } kill func() { _ cmd.Process.Kill() } sendInterrupt func() error { return cmd.Process.Signal(syscall.SIGTERM) } err waitForServerListening(port) return } func waitForServerListening(port string) error { for i : 0; i 30; i { conn, _ : net.Dial(tcp, net.JoinHostPort(localhost, port)) if conn ! nil { conn.Close() return nil } time.Sleep(100 * time.Millisecond) } return fmt.Errorf(nothing seems to be listening on localhost:%s, port) } func randomString(n int) string { var letters []rune(abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789) s : make([]rune, n) for i : range s { s[i] letters[rand.Intn(len(letters))] } return string(s) }LaunchTestProgram的职责拆解buildBinary用go build -o 随机名-temp-testbinary编译当前目录的程序二进制名用randomString生成避免测试并发时的命名冲突runServer用os/exec启动二进制返回两个闭包——sendInterrupt通过cmd.Process.Signal(syscall.SIGTERM)给进程发SIGTERMkill直接cmd.Process.Kill()强杀waitForServerListening轮询每 100ms 一次最多 30 次约 3 秒用net.Dial探测localhost:port的 TCP 端口是否已经监听cleanup负责在测试结束时强杀进程并删除临时二进制文件保证测试环境干净。作者也坦诚这段代码不算漂亮但重要的是LaunchTestProgram这个导出函数其余未导出函数只是无趣的样板。这正是验收测试的特点仪式性代码通常只需写一次之后就可以被遗忘换来测试主体代码的极其简洁。第二步编写验收测试本身团队希望为两个程序各写一个验收测试一个有优雅停机、一个没有让读者直观对比行为差异。有了LaunchTestProgram之后测试写起来非常简单并且可以复用assert.CanGet/CantGet之类的辅助函数package main import ( testing time github.com/quii/go-graceful-shutdown/acceptancetests github.com/quii/go-graceful-shutdown/assert ) const ( port 8080 url http://localhost: port ) func TestGracefulShutdown(t *testing.T) { cleanup, sendInterrupt, err : acceptancetests.LaunchTestProgram(port) if err ! nil { t.Fatal(err) } t.Cleanup(cleanup) // just check the server works before we shut things down assert.CanGet(t, url) // fire off a request, and before it has a chance to respond send SIGTERM. time.AfterFunc(50*time.Millisecond, func() { assert.NoError(t, sendInterrupt()) }) // Without graceful shutdown, this would fail assert.CanGet(t, url) // after interrupt, the server should be shutdown, and no more requests will work assert.CantGet(t, url) }这段测试的逻辑非常清晰启动程序并注册t.Cleanup(cleanup)保证无论测试成败都会清理assert.CanGet先确认服务器正常工作time.AfterFunc(50*time.Millisecond, ...)在 50ms 后发送SIGTERM——而此刻前一个请求还在途中因为SlowHandler会 sleep于是我们可以验证进程收到 SIGTERM 后in-flight 请求依然能拿到响应发送中断后再请求一次这次在没有优雅停机的版本下会失败assert.CantGet验证关闭后服务器不再接受新请求。assert.CanGet的实现CantGet与之对称只是断言失败方向相反展示了如何在测试中安全地做带超时的 HTTP 请求func CanGet(t testing.TB, url string) { errChan : make(chan error) go func() { res, err : http.Get(url) if err ! nil { errChan - err return } res.Body.Close() errChan - nil }() select { case err : -errChan: NoError(t, err) case -time.After(3 * time.Second): t.Errorf(timed out waiting for request to %q, url) } }它在一个 goroutine 中发出GET请求通过 channel 回传结果并用select配合 3 秒超时兜底避免测试无限挂起。再次强调Go 标准库自带编写验收测试所需的全部工具不需要任何特殊框架。第三步运行结果与小投入大回报在作者仓库中的实际运行输出如下go test -count1 ./... ok github.com/quii/go-graceful-shutdown 0.196s ? github.com/quii/go-graceful-shutdown/acceptancetests [no test files] ok github.com/quii/go-graceful-shutdown/acceptancetests/withgracefulshutdown 4.785s ok github.com/quii/go-graceful-shutdown/acceptancetests/withoutgracefulshutdown 2.914s ? github.com/quii/go-graceful-shutdown/assert [no test files]注意-count1用于禁用 Go 的测试结果缓存确保真实执行。观察运行时间两个验收测试各需 25 秒因为要构建二进制、启动进程、等待端口而单元测试包几乎瞬间完成。这些测试带来的价值读者可以看着示例程序并确信示例真的能跑从而信任包所宣称的行为作为作者获得快速反馈和在真实环境中的强大信心。从单元测试到验收测试组合成完整的测试策略至此我们可以完整总结两者的分工维度单元测试验收测试测试范围系统局部函数/模块整个系统黑盒访问内部可以不可以速度快慢失败定位精确通常只给现象不给根因反馈内部质量有没有Mock常用不用全真实变更触发因素实现细节变化外部行为变化正确的组合不是二选一而是金字塔大量快速单元测试 少量验收测试。单元测试负责快速反馈与内部质量验收测试负责确认整个系统真的按用户期望工作。更复杂系统的验收测试验收测试的写法高度依赖目标系统的形态但原则一致——把系统当作黑盒网站测试应像用户一样操作使用无头浏览器如 Selenium点击链接、填写表单、提交等RESTful API使用 HTTP 客户端发送请求并断言响应。非平凡系统通常不是单进程应用还会依赖数据库等其他系统。此时需要用工具如 docker-compose在本地自动化地拉起所需的依赖环境再在其上运行验收测试。进阶方向规模化验收测试在 Learn Go with Tests 的后续章节 scaling-acceptance-tests.md 中作者进一步把本章的思路扩展到大型系统用Specification规格→ Driver → System的分层结构解耦期望行为与实现细节规格只表达领域内不可妥协的本质复杂度essential complexityDriver 负责把规格翻译成具体的系统调用HTTP、gRPC 等从而使同一份规格可以被 HTTP 服务器、gRPC 服务器乃至纯领域函数通过适配器模式复用借助 Testcontainers 在测试中程序化地构建 Docker 镜像、管理容器生命周期甚至可以在本地、staging、生产环境运行同一份规格通过testing.Short()标志与go test -short ./...把耗时较长的验收测试与快速单元测试分离配合 Makefile 提供良好的开发者体验这套自顶向下top-down的开发方式也呼应了 math.md 中 clockface SVG 时钟一节的实践——先写一个什么时候算完成的高层验收测试作为北极星再以 TDD 逐步驱动单元实现直到验收测试通过。关于何时该写验收测试作者给出的自问清单也值得收藏这是边界情况吗——优先单元测试这是非技术人员也经常谈论的核心功能吗——需要高置信度写验收测试我描述的是用户旅程而非具体函数吗——验收测试单元测试能否给我足够的信心——如果已有覆盖同一旅程的验收测试、只是输入组合变化单元测试更划算。提升开源项目质量如果你在编写打算对外分享的包作者强烈建议创建一个简单的示例程序展示包的用法并投入精力为它编写易读的验收测试——这既给自己也给潜在用户信心。和 Go 官方的 Testable Examples 一样这份额外的开发者体验投入能显著建立信任并降低你自己的长期维护成本。事实上本仓库 README.md 中 intro-to-acceptance-tests.md 一节的定位正是以优雅停机 HTTP 服务器为真实案例学习如何为代码编写验收测试而它在本书 SUMMARY.md 中与 scaling-acceptance-tests.md、working-without-mocks.md 一起构成了Testing fundamentals测试基础板块。小结本文从一个生产级的痛点切入完整演示了验收测试的引入过程问题K8s 终止 Pod 时发送SIGTERM忽略它会导致 in-flight 请求丢失、测试闪断、用户体验恶化方案用os/signal.Notify监听信号用net/http/Server.Shutdown优雅收尾两者皆是标准库能力验证单元测试不足以建立信心手动测试不可持续于是用LaunchTestProgram封装构建 → 启动 → 等待端口 → 发信号 → 清理再写两个黑盒验收测试对比有/无优雅停机的行为差异原则验收测试是黑盒、零 mock、只断言外部行为成本高、定位难因此要与大量快速单元测试构成测试金字塔配合 lead time 目标如 10 分钟内持续交付。无论你构建的是 HTTP API、带数据库的微服务还是面向浏览器的 Web 应用验收测试的核心哲学始终如一像用户一样使用你的系统并在真实运行环境中验证它。把这条原则与分层解耦规格 / 驱动 / 实现结合你就能在享受快速反馈的同时让系统始终处于可发布的状态。【免费下载链接】learn-go-with-testsLearn Go with test-driven development项目地址: https://gitcode.com/gh_mirrors/le/learn-go-with-tests创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Learn Go with Tests 验收测试入门：用黑盒测试守护 HTTP 服务器的优雅停机
Learn Go with Tests 验收测试入门用黑盒测试守护 HTTP 服务器的优雅停机【免费下载链接】learn-go-with-testsLearn Go with test-driven development项目地址: https://gitcode.com/gh_mirrors/le/learn-go-with-tests本指南来自开源仓库 Learn Go with Tests 的Testing fundamentals章节核心围绕 intro-to-acceptance-tests.md 展开以HTTP 服务在 Kubernetes 下优雅停机这一真实生产问题为切入点系统讲解什么是验收测试Acceptance Tests、它和单元测试的边界以及如何用 Go 标准库自带的能力编写真正端到端的黑盒测试。读完本文你将掌握基于os/signal、net/http构建优雅停机服务的方法并能够独立编写构建真实程序 → 启动 → 发请求 → 发送 SIGTERM → 验证行为的完整验收测试流程。场景驱动为什么需要优雅停机文中以$WORK作者所在团队的真实经历为背景他们的服务运行在 KubernetesK8s集群上团队以 DORA 指标 为标准追求每天多次向生产环境部署小而增量的改动。K8s 在需要终止一个 Pod实践上就是我们的软件进程时会触发一套终止生命周期termination lifecycle其中关键的一步是向软件发送SIGTERM信号语义相当于你需要自行关闭自己把正在做的工作收尾因为过了某个宽限期grace period之后我会发送SIGKILL到那时就是熄灯走人了。SIGKILL一旦发出程序正在进行的任何工作都会被立即中断。没有优雅停机的代价如果忽视SIGTERM取决于软件的性质可能引发各种问题。作者团队遇到的具体问题是in-flight HTTP 请求当自动化测试正在请求 API 时如果 K8s 决定停止 Pod服务器进程瞬间死亡测试收不到响应直接失败失败触发事故频道的告警迫使开发者停下手中工作去处理这类间歇性失败是对团队的持续骚扰。这种问题并不只存在于测试场景。真实用户向系统发送请求进程在请求处理途中被终止用户大概率会收到一个 5xx 错误——这显然不是想提供的用户体验。而优雅停机要做的正是停止接收新的请求关闭 listener允许所有 in-flight 请求跑完然后再终止进程。优雅停机的标准库实现Server.Shutdown os/signal.NotifyGo 标准库已经为这个需求提供了现成机制无需引入任何第三方依赖net/http/Server.Shutdown优雅地关闭服务器而不中断任何活跃连接。其工作机制是先关闭所有打开的 listeners再关闭所有空闲连接然后无限期等待连接回到空闲状态并关闭如果传入的 context 在关闭完成前过期则返回该 context 的错误否则返回关闭底层 Listener 时产生的错误。这意味着我们完全可以控制宽限期的上限——通过 context 超时。os/signal.Notify把收到的系统信号如SIGTERM转发到我们提供的 channel 上从而让我们可以在收到信号时执行自定义逻辑。两者结合就能实现监听SIGTERM→ 优雅关闭。graceful shutdown 包一个装饰器模式的设计为了让这段逻辑可复用作者编写了github.com/quii/go-graceful-shutdown库它向*http.Server提供一个装饰器函数Decorator pattern在检测到SIGTERM时自动调用其Shutdown方法。典型用法如下func main() { var ( ctx context.Background() httpServer http.Server{Addr: :8080, Handler: http.HandlerFunc(acceptancetests.SlowHandler)} server gracefulshutdown.NewServer(httpServer) ) if err : server.ListenAndServe(ctx); err ! nil { // this will typically happen if our responses arent written before the ctx deadline, not much can be done log.Fatalf(uh oh, didnt shutdown gracefully, some responses may have been lost %v, err) } // hopefully, youll always see this instead log.Println(shutdown gracefully! all responses were sent) }结构非常直白创建一个net/http.Server监听:8080用库包装它再用包装后的实例调用ListenAndServe。这里的SlowHandler内部带有一个time.Sleep来延迟响应——这正是为了给人工测试留出发送SIGTERM的时间窗口。注意ListenAndServe返回错误时通常意味着响应没有在 context 截止时间前写完而打印 shutdown gracefully! all responses were sent 则是我们希望永远看到的日志。单元测试的盲区与手动测试的痛点在编写gracefulshutdown包时作者写了单元测试来证明行为正确并获得了激进重构的信心。但仍然不敢说它真的能工作。于是他们加了一个cmd包把库编译成一个真实程序手动启动它、发一个 HTTP 请求、然后发送SIGTERM观察现象。作者明确指出工程师的直觉应该对这种手动测试感到不适。手动测试无聊不可扩展不准确浪费人力。如果你打算分享一个包同时又想让它保持简单、廉价地演进手动测试是撑不住的。这正是引入验收测试的契机。什么是验收测试本书其他章节大多在讲单元测试它擅长支撑无畏重构、驱动良好的模块化设计、防止回归、提供快速反馈。但单元测试天然只覆盖系统的局部单靠它往往不足以构成有效的测试策略。我们想让系统始终处于可发布状态又不能依赖手动测试于是需要另一种测试验收测试。黑盒测试的本质验收测试是一种黑盒测试black-box test有时也被称为功能测试functional test。它应该像系统用户那样去使用系统测试代码无法访问系统内部实现只能使用系统的公开接口它只能对整个系统做断言观察的是对外表现出的行为正因为如此测试无法使用让测试通过但不证明问题被解决的特殊旁路手段。这与单元测试文件应放在独立测试包中例如package mypkg_test而非package mypkg的原则一脉相承——测试代码与被测对象之间保持距离反而更可信。收益通过时你确知整个系统的行为符合预期比手动测试更准确、更快、更省力写得好时它们就是准确、可验证的系统文档不会落入文档与真实行为脱节的陷阱零 mock全部是真实交互。与单元测试相比的代价编写成本高运行时间长依赖系统整体设计失败时通常不给出根因调试困难不反馈系统内部质量——即便内部实现是一坨垃圾验收测试也可能通过由于黑盒特性并非所有场景都适合用它覆盖。因此只依赖验收测试是愚蠢的它会失去单元测试的大量优点一个堆满验收测试的系统通常会在维护成本和交付时间上付出代价。顺带一提Lead Time 与测试金字塔文中的Lead time指从一次 commit 合并到 main 分支到它部署到生产环境的耗时。不同团队从数周甚至数月到几分钟不等作者所在团队遵循 DORA 研究结论希望把 lead time 控制在10 分钟以内。可靠且 lead time 良好的系统需要平衡的测试策略通常用 Test Pyramid测试金字塔 来描述底层大量快速的单元测试上层少量端到端的验收测试。实战如何编写基础的验收测试回到最初的问题包本身完全可以单元测试但单元测试没能带来足够信心。我们需要的是与真实运行程序集成的验证并把之前的手工检查自动化。高层次的测试步骤构建程序运行它并等待它监听在8080端口向服务器发送一个 HTTP 请求在服务器有机会返回响应之前发送SIGTERM观察是否仍然收到了响应。第一步构建并运行被测程序需要一个acceptancetests包来封装构建 启动 清理的仪式性代码。核心导出函数是LaunchTestProgrampackage acceptancetests import ( fmt math/rand net os os/exec path/filepath syscall time ) const ( baseBinName temp-testbinary ) func LaunchTestProgram(port string) (cleanup func(), sendInterrupt func() error, err error) { binName, err : buildBinary() if err ! nil { return nil, nil, err } sendInterrupt, kill, err : runServer(binName, port) cleanup func() { if kill ! nil { kill() } os.Remove(binName) } if err ! nil { cleanup() // even though its not listening correctly, the program could still be running return nil, nil, err } return cleanup, sendInterrupt, nil } func buildBinary() (string, error) { binName : randomString(10) - baseBinName build : exec.Command(go, build, -o, binName) if err : build.Run(); err ! nil { return , fmt.Errorf(cannot build tool %s: %s, binName, err) } return binName, nil } func runServer(binName string, port string) (sendInterrupt func() error, kill func(), err error) { dir, err : os.Getwd() if err ! nil { return nil, nil, err } cmdPath : filepath.Join(dir, binName) cmd : exec.Command(cmdPath) if err : cmd.Start(); err ! nil { return nil, nil, fmt.Errorf(cannot run temp converter: %s, err) } kill func() { _ cmd.Process.Kill() } sendInterrupt func() error { return cmd.Process.Signal(syscall.SIGTERM) } err waitForServerListening(port) return } func waitForServerListening(port string) error { for i : 0; i 30; i { conn, _ : net.Dial(tcp, net.JoinHostPort(localhost, port)) if conn ! nil { conn.Close() return nil } time.Sleep(100 * time.Millisecond) } return fmt.Errorf(nothing seems to be listening on localhost:%s, port) } func randomString(n int) string { var letters []rune(abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789) s : make([]rune, n) for i : range s { s[i] letters[rand.Intn(len(letters))] } return string(s) }LaunchTestProgram的职责拆解buildBinary用go build -o 随机名-temp-testbinary编译当前目录的程序二进制名用randomString生成避免测试并发时的命名冲突runServer用os/exec启动二进制返回两个闭包——sendInterrupt通过cmd.Process.Signal(syscall.SIGTERM)给进程发SIGTERMkill直接cmd.Process.Kill()强杀waitForServerListening轮询每 100ms 一次最多 30 次约 3 秒用net.Dial探测localhost:port的 TCP 端口是否已经监听cleanup负责在测试结束时强杀进程并删除临时二进制文件保证测试环境干净。作者也坦诚这段代码不算漂亮但重要的是LaunchTestProgram这个导出函数其余未导出函数只是无趣的样板。这正是验收测试的特点仪式性代码通常只需写一次之后就可以被遗忘换来测试主体代码的极其简洁。第二步编写验收测试本身团队希望为两个程序各写一个验收测试一个有优雅停机、一个没有让读者直观对比行为差异。有了LaunchTestProgram之后测试写起来非常简单并且可以复用assert.CanGet/CantGet之类的辅助函数package main import ( testing time github.com/quii/go-graceful-shutdown/acceptancetests github.com/quii/go-graceful-shutdown/assert ) const ( port 8080 url http://localhost: port ) func TestGracefulShutdown(t *testing.T) { cleanup, sendInterrupt, err : acceptancetests.LaunchTestProgram(port) if err ! nil { t.Fatal(err) } t.Cleanup(cleanup) // just check the server works before we shut things down assert.CanGet(t, url) // fire off a request, and before it has a chance to respond send SIGTERM. time.AfterFunc(50*time.Millisecond, func() { assert.NoError(t, sendInterrupt()) }) // Without graceful shutdown, this would fail assert.CanGet(t, url) // after interrupt, the server should be shutdown, and no more requests will work assert.CantGet(t, url) }这段测试的逻辑非常清晰启动程序并注册t.Cleanup(cleanup)保证无论测试成败都会清理assert.CanGet先确认服务器正常工作time.AfterFunc(50*time.Millisecond, ...)在 50ms 后发送SIGTERM——而此刻前一个请求还在途中因为SlowHandler会 sleep于是我们可以验证进程收到 SIGTERM 后in-flight 请求依然能拿到响应发送中断后再请求一次这次在没有优雅停机的版本下会失败assert.CantGet验证关闭后服务器不再接受新请求。assert.CanGet的实现CantGet与之对称只是断言失败方向相反展示了如何在测试中安全地做带超时的 HTTP 请求func CanGet(t testing.TB, url string) { errChan : make(chan error) go func() { res, err : http.Get(url) if err ! nil { errChan - err return } res.Body.Close() errChan - nil }() select { case err : -errChan: NoError(t, err) case -time.After(3 * time.Second): t.Errorf(timed out waiting for request to %q, url) } }它在一个 goroutine 中发出GET请求通过 channel 回传结果并用select配合 3 秒超时兜底避免测试无限挂起。再次强调Go 标准库自带编写验收测试所需的全部工具不需要任何特殊框架。第三步运行结果与小投入大回报在作者仓库中的实际运行输出如下go test -count1 ./... ok github.com/quii/go-graceful-shutdown 0.196s ? github.com/quii/go-graceful-shutdown/acceptancetests [no test files] ok github.com/quii/go-graceful-shutdown/acceptancetests/withgracefulshutdown 4.785s ok github.com/quii/go-graceful-shutdown/acceptancetests/withoutgracefulshutdown 2.914s ? github.com/quii/go-graceful-shutdown/assert [no test files]注意-count1用于禁用 Go 的测试结果缓存确保真实执行。观察运行时间两个验收测试各需 25 秒因为要构建二进制、启动进程、等待端口而单元测试包几乎瞬间完成。这些测试带来的价值读者可以看着示例程序并确信示例真的能跑从而信任包所宣称的行为作为作者获得快速反馈和在真实环境中的强大信心。从单元测试到验收测试组合成完整的测试策略至此我们可以完整总结两者的分工维度单元测试验收测试测试范围系统局部函数/模块整个系统黑盒访问内部可以不可以速度快慢失败定位精确通常只给现象不给根因反馈内部质量有没有Mock常用不用全真实变更触发因素实现细节变化外部行为变化正确的组合不是二选一而是金字塔大量快速单元测试 少量验收测试。单元测试负责快速反馈与内部质量验收测试负责确认整个系统真的按用户期望工作。更复杂系统的验收测试验收测试的写法高度依赖目标系统的形态但原则一致——把系统当作黑盒网站测试应像用户一样操作使用无头浏览器如 Selenium点击链接、填写表单、提交等RESTful API使用 HTTP 客户端发送请求并断言响应。非平凡系统通常不是单进程应用还会依赖数据库等其他系统。此时需要用工具如 docker-compose在本地自动化地拉起所需的依赖环境再在其上运行验收测试。进阶方向规模化验收测试在 Learn Go with Tests 的后续章节 scaling-acceptance-tests.md 中作者进一步把本章的思路扩展到大型系统用Specification规格→ Driver → System的分层结构解耦期望行为与实现细节规格只表达领域内不可妥协的本质复杂度essential complexityDriver 负责把规格翻译成具体的系统调用HTTP、gRPC 等从而使同一份规格可以被 HTTP 服务器、gRPC 服务器乃至纯领域函数通过适配器模式复用借助 Testcontainers 在测试中程序化地构建 Docker 镜像、管理容器生命周期甚至可以在本地、staging、生产环境运行同一份规格通过testing.Short()标志与go test -short ./...把耗时较长的验收测试与快速单元测试分离配合 Makefile 提供良好的开发者体验这套自顶向下top-down的开发方式也呼应了 math.md 中 clockface SVG 时钟一节的实践——先写一个什么时候算完成的高层验收测试作为北极星再以 TDD 逐步驱动单元实现直到验收测试通过。关于何时该写验收测试作者给出的自问清单也值得收藏这是边界情况吗——优先单元测试这是非技术人员也经常谈论的核心功能吗——需要高置信度写验收测试我描述的是用户旅程而非具体函数吗——验收测试单元测试能否给我足够的信心——如果已有覆盖同一旅程的验收测试、只是输入组合变化单元测试更划算。提升开源项目质量如果你在编写打算对外分享的包作者强烈建议创建一个简单的示例程序展示包的用法并投入精力为它编写易读的验收测试——这既给自己也给潜在用户信心。和 Go 官方的 Testable Examples 一样这份额外的开发者体验投入能显著建立信任并降低你自己的长期维护成本。事实上本仓库 README.md 中 intro-to-acceptance-tests.md 一节的定位正是以优雅停机 HTTP 服务器为真实案例学习如何为代码编写验收测试而它在本书 SUMMARY.md 中与 scaling-acceptance-tests.md、working-without-mocks.md 一起构成了Testing fundamentals测试基础板块。小结本文从一个生产级的痛点切入完整演示了验收测试的引入过程问题K8s 终止 Pod 时发送SIGTERM忽略它会导致 in-flight 请求丢失、测试闪断、用户体验恶化方案用os/signal.Notify监听信号用net/http/Server.Shutdown优雅收尾两者皆是标准库能力验证单元测试不足以建立信心手动测试不可持续于是用LaunchTestProgram封装构建 → 启动 → 等待端口 → 发信号 → 清理再写两个黑盒验收测试对比有/无优雅停机的行为差异原则验收测试是黑盒、零 mock、只断言外部行为成本高、定位难因此要与大量快速单元测试构成测试金字塔配合 lead time 目标如 10 分钟内持续交付。无论你构建的是 HTTP API、带数据库的微服务还是面向浏览器的 Web 应用验收测试的核心哲学始终如一像用户一样使用你的系统并在真实运行环境中验证它。把这条原则与分层解耦规格 / 驱动 / 实现结合你就能在享受快速反馈的同时让系统始终处于可发布的状态。【免费下载链接】learn-go-with-testsLearn Go with test-driven development项目地址: https://gitcode.com/gh_mirrors/le/learn-go-with-tests创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
排查与解决方案)
