写C代码的语言测人，十有八九都经历过这样的试工夜晚：指针越界，段错误，语言测gdb里backtrace一长串，试工看得人头皮发麻。语言测更气人的试工是，代码逻辑明明“看起来”没问题，语言测可一跑就崩。试工这时候你才意识到，语言测光靠编译器那点警告和printf大法，试工根本不够用。语言测C语言测试工具，试工不是语言测锦上添花，是试工救命稻草。
我用过的语言测第一个正经工具是Valgrind。说实话，初次接触它的体验并不愉快，命令行参数一堆，输出格式也古板。但当你盯着它报出的“Invalid read of size 4”和那一串调用栈，你会突然明白，原来内存泄漏和越界访问在它面前无处遁形。有个项目，跑起来偶尔闪退，找了三天没头绪。用Valgrind一跑，直接定位到某个结构体数组下标越界——那个下标是用户输入算出来的，负数。没有它，我可能还在那个深夜对着屏幕怀疑人生。
不过Valgrind也有脾气。它慢，跑一个测试用例的时间够你泡三杯咖啡。所以后来我学乖了，日常单元测试用别的，专门挑那种“疑似内存问题”的疑难杂症才请它出马。工具得搭配着用，就像你工具箱里不能只有一把锤子。
说到单元测试，C语言这边绕不开Unity和CMocka。Unity轻量，适合嵌入式那种资源受限的环境，跑起来快，断言也直观。CMocka则多了mock功能，对付依赖数据库或硬件接口的代码很有用。我有个同事，写了个网络模块的测试，硬是用CMocka把socket函数全mock掉，模拟各种异常返回，把边界条件测了个遍。他说这叫“把系统故障提前到开发环境里演习”，我觉得这话挺在理。
但工具再强，也架不住人懒。测试覆盖率是个好东西，可它只告诉你哪行代码没跑到，不告诉你逻辑对不对。我见过有人把覆盖率刷到95%，结果核心算法算错了一个符号，测试照样全绿。所以别迷信数字，覆盖率是参考，不是目标。真正有效的测试，是你自己心里清楚“这段代码最容易在什么情况下出错”，然后专门去构造那种情况。
还有个小众但实用的工具叫Gcov，配合GCC用。它能精确到每一行执行了多少次，比那种纯百分比报告有用多了。排查死代码、确认某个分支是否真的被走到，它比人眼靠谱。有一次我重构一段状态机逻辑，用Gcov一看，有个case分支从没执行过，仔细一查，原来前面的条件判断把那条路径永远挡死了。代码删掉，逻辑反而清晰了。
工具链里还有Sanitizer系列，AddressSanitizer和UndefinedBehaviorSanitizer，编译时加个参数就能用。它们比Valgrind快，而且能抓未定义行为——比如有符号整数溢出，这种错在常规测试里根本不会吭声，但到生产环境就成定时炸弹。我至今记得第一次用ASan抓到堆缓冲区溢出时那种感觉，像在自家地毯下发现一颗螺丝钉，不致命，但你知道它早晚会硌脚。
说到底，测试工具不是万能药。它们能帮你找出内存错误、逻辑漏洞、未定义行为，但前提是你得愿意花时间写测试、跑测试、看报告。C语言给了你完全的控制权，也给了你完全搞砸的自由。工具只是把那些“自由”造成的后果提前暴露出来，让你在交付之前就疼一下，而不是上线之后被用户骂醒。
所以，别嫌麻烦。装个Valgrind，开个ASan，写几个Unity测试用例，成本不高，但换来的是一夜好觉。至少下次段错误出现时，你不会再对着屏幕发呆，而是能冷静地敲下那条命令，等着它告诉你答案。