文/一个踩过无数次线上坑之后学会做减法的人
我团队里有个小伙子，上个月负责一个核心接口的重构。改完之后他自己做了充分的测试——单元测试覆盖率百分之九十、集成测试跑通了所有场景、压力测试一千并发响应时间稳定在五十毫秒以内。他觉得万无一失，提了上线申请。
上线之后，一切正常。五分钟后，监控突然报警——接口超时率飙升到百分之十五。他一脸茫然：”我全都测过了啊，没问题的。”
我走到他工位旁边说：”把服务停掉，先别找原因。给你一分钟，写一个最简单的接口，什么逻辑都没有，就返回’Hello’。”
他飞快地写了一个，部署，测试——那个裸接口也超时。
“问题不在你改的那段逻辑上，”我说，”问题在你改了这个服务依赖的底层环境。你的Hello World已经告诉我们了，这条路本身就不通。”
他后来排查了半天，发现是他在重构过程中升级了一个底层HTTP客户端的版本，新版本默认开启了一个连接池复用策略，而那个策略跟当前部署环境里的某个代理不兼容。跟业务逻辑半毛钱关系都没有，但他的所有”充分的测试”全都没发现这个问题，因为他测试的时候用的是老版本的客户端。
而那个只有三行代码的”Hello”接口，一秒钟就抓到了根源。
你有多久没写过”最小测试”了
这个小伙子不是个例。我在这个行业里见过太多程序员，越到后来，越不愿意写”小测试”。
刚入行的时候，写什么都先用一个最小示例跑一遍。要连接数据库？先写个查询SELECT 1确认连通性。要调用第三方API？先写个请求GET /ping确认对方服务正常。要用新框架？先建个最简项目把首页搭出来再说。
那时候的Hello World思维无处不在。每引入一个新技术、每改动一个底层依赖、每切换一个环境，大家都会下意识地用最简代码去验证一下”路是通的”。
但工作两三年之后，这种习惯慢慢消失了。大家开始”信任”一些东西——信任公司的基础设施不会出问题、信任第三方库的兼容性、信任自己脑子里对系统架构的理解。然后出了问题，花大量时间在复杂的业务逻辑里找原因，各种日志、链路追踪、火焰图全上，折腾了半天，最后发现是环境变量配错了。
那个”小测试”到底小在哪里
写一个Hello World级别的测试，看起来特别”没技术含量”。一行输出而已，谁不会啊。
但它的价值从来不在于”会”，而在于”隔离”。
当你把系统里所有复杂的业务逻辑全部剥离掉，只剩一个最干净的请求/响应通路时，这个通路就变成了一个”基线”。你在它上面测得的所有结果，都是这条路径在不受任何干扰的情况下的真实表现。它像一把尺子，你拿它量完，就知道系统的底层有没有病变。
再往上一层，你可以把这个”裸通路”当成一个锚点。每当你往系统里加一个依赖、加一个组件、加一层逻辑，你就在这个锚点的基础上做增量测试。加了数据库，测得慢了一点点，那是数据库的锅。加了缓存，测得快了很多，那是缓存立功了。加了消息队列，延迟突然从两毫秒变成了五百毫秒，那你可以非常肯定地说：问题出在队列这个组件上，而不是代码写错了。
这种”逐层叠加、逐层验证”的方法，比集成好所有功能再一起测、出了问题再大海捞针式地排查，效率高了不止一个数量级。
而这一切的起点，就是那个被很多人看不起的Hello World。
每一个上线前的”小测试”，都比你想的值钱
我以前在一个金融科技公司待过，我们有个不成文的规定：每次发布前，除了常规的回归测试之外，发布工程师必须在生产环境（严格来说是一个隔离的预发布环境）跑一遍”裸通路测试”——就是确认服务能启动、健康检查端点能返回200、数据库连接池能拿到连接、缓存能读写、消息队列能收发。
这个测试清单里全都是”Hello World级别”的简单验证。不需要知道业务含义，不需要理解复杂的订单状态机，不需要搞懂风控规则。就是一个程序化的、机械的、任何人都能执行的”生存确认”。
后来有一次真的救了我们。那次发布改动了数据库连接字符串的配置方式，测试环境用的是内网地址，生产环境用了不同的端口映射。所有业务测试全部通过，因为测试环境一切正常。但在预发布环境跑”生存确认”的时候，数据库连通性那一项红了——服务启动之后连不上数据库，健康检查失败。
发布被紧急叫停。运维排查发现是生产环境的防火墙规则最近被改过，新配置的端口没开白名单。如果当时没有这个Hello World级别的检查，这版代码推到线上，等着我们的就是开机五分钟、报警响满全屏的灾难现场。
为什么我们总在”小测试”上翻车
说来也怪，越是简单的测试，越容易被忽视。复杂的单元测试、自动化UI测试、全链路压测，大家都当回事，投入大量人力物力去建设。但”写个最简程序跑一下试试”这种一分钟的事，反而没人安排，没人跟进，全靠工程师自觉。
而自觉这个东西，在忙碌的、被需求追着跑的工作节奏里，是最容易被牺牲的。你本来想”先写个demo验证一下”再写业务代码，但产品经理站在你后面问”这个功能什么时候能上”，你说”等我五分钟写个验证”，他说”五分钟也是时间，你先写业务代码，有问题再说”。
然后问题就真的来了。而且来的时候，你花的不只是五分钟，可能是五十分钟、五个小时，甚至是第二天凌晨三点。
那个你不屑于写的Hello World，才是你真正的底线
我在团队里现在立了个规矩：每个技术方案评审的时候，必须回答一个问题——”这个方案的最简验证方案是什么？”
意思就是，不管你设计的系统多复杂，你要告诉我，你打算怎么用最少的时间、最少的代码、最少的依赖，去证明这条技术路线走得通、这个环境配置正确、这个核心组件能正常工作。
有人问我，这个最简验证方案的标准是什么。我说标准就是：一个完全不了解你业务逻辑的人，按照你写的操作步骤，能在三分钟之内看到预期的结果。
通俗点说，就是能跑出你的Hello World。
这个要求看起来低，实际上一点也不低。它逼着你去思考：我到底依赖了什么？哪些是必要的？哪些可以先忽略？哪些可能有坑，需要先踩一脚试试深浅？这个思考过程本身，比跑出来的那个结果还重要。
写在最后
那个小伙子后来被我推荐去负责一个新项目的技术预研了。走之前他跟我说：”我现在习惯改了，每个新组件上手之前，先花十分钟写个demo跑通，然后再写业务。”
我说那就对了。以后不管做得多深、写得多复杂，保持这个习惯。你永远不知道底层什么时候会出问题，也不知道哪次升级会带来什么意外。但你有一个东西是不会变的——那个你随手写的、只有几行代码的、输出”Hello”的测试程序。
它从来没有业务价值，但它有生存价值。
只要它还能跑通，你就还有底气说：我的系统，根还是稳的。