家里新装了千兆宽带，路由器一通设置，网速拉满，但过两天突然掉线、DNS解析慢、甚至远程管理页面打不开——你可能没想到，问题源头藏在设备固件里那几行没经过验证的代码里。
写代码前先写测试？不是折腾，是防翻车
很多宽带设备厂商用嵌入式Linux系统开发固件，比如OpenWrt平台。工程师改个DHCP租期逻辑、加个QoS限速规则，随手敲完就编译烧录。结果用户一用，某些光猫型号下PPPoE重拨失败，或者IPv6前缀通告异常。这类问题往往要等用户投诉才暴露，修起来又得发补丁包，耗时耗力。
测试驱动开发（TDD）就是反着来：先写一个单元测试，明确“这个DHCP模块必须在断网后30秒内自动重连”，再写代码让它通过。哪怕只是几行C函数或Shell脚本，只要能隔离运行、有明确输入输出，就能测。
举个真用得上的例子
假设你要给路由器的带宽监控脚本加个功能：当上行流量连续5分钟超阈值，自动降级QoS策略。不测直接上线？很可能误判——比如视频会议突发上传，就把用户网速砍半了。
按TDD流程，第一步不是写主逻辑，而是写个测试：
#!/bin/sh
# test_qos_throttle.sh
. ./qos.sh
test_throttle_triggered() {
# 模拟连续5次检测到上行>90%
mock_uplink_usage "95 92 96 91 94"
run_throttle_check
[ "$QOS_LEVEL" = "low" ]
}
run_test test_throttle_triggered跑不通？说明逻辑没写对，或者边界没考虑全（比如刚启动时数据不足5条怎么处理）。直到测试绿了，再把真实网卡读数、配置写入这些细节补上。
这就像宽带师傅上门前先检查工具包：网线测试仪有没有电、水晶头压线钳是否顺手。工具齐了，现场才不会手忙脚乱。
为什么宽带场景特别需要它
家庭宽带设备资源紧：内存小、CPU弱、存储常是只读Flash。没法像服务器那样堆监控告警。单元测试轻量、快、可重复，一个脚本跑几十毫秒，CI流水线上批量验所有机型适配情况。某品牌在升级Wi-Fi6驱动前，靠200+个单元测试卡住了7个会导致STA连接中断的内存越界bug，比实机摸排快了三天。
别觉得这是大厂专利。你自己刷Padavan固件、写个定时重启脚本，也可以照着做：把判断网络是否宕机的函数单独抽出来，用curl模拟返回码，写两个测试——一个返回200算在线，一个超时或404算离线。测过了，心里才有底。