写代码前先写测试？一个买菜清单引发的测试驱动开发实例

老张最近学写小程序，想做个买菜清单App——勾选青菜、鸡蛋、豆腐，自动统计总价。他照着教程吭哧写完界面和计算逻辑，结果一测发现：输入‘豆腐 3.5元’时总价总少算0.1元。改了三回，还是出错。

换个思路：先写“考卷”，再交“答卷”

他朋友小李看了直摇头：“你试试‘测试驱动开发’——不是边写边测，是先写测试用例，再写能让测试通过的代码。”

比如，小李让老张第一件事不是敲UI代码，而是写下这行“考卷”：

assertEqual(calculateTotal([{'name': '青菜', 'price': 2.5}, {'name': '鸡蛋', 'price': 6.8}]), 9.3)

这行代码没实现任何功能，只是声明：“当输入这两样菜，总价必须等于9.3”。运行？报错——因为calculateTotal函数根本不存在。

然后，只写最简代码让测试通过

老张硬着头皮，只写了三行：

def calculateTotal(items):
    total = 0
    for item in items:
        total += item['price']
    return total

再跑测试——绿灯亮了。他没加任何多余功能：不处理折扣、不校验价格格式、不防小数精度坑。就干一件事：把price加起来。

接着，他加第二道“考卷”：

assertEqual(calculateTotal([{'name': '豆腐', 'price': 3.5}]), 3.5)

再跑——还是绿的。这时他突然意识到：之前总价出错，是因为用了float直接相加。他马上补上一行修复：

return round(total, 1)

所有测试继续通过。没有盲猜，没有反复试错，每一步都看得见反馈。

生活里类似场景不少：写个家庭记账脚本、整理照片按日期重命名、批量改Excel表头……与其先堆满代码再抓耳挠腮找bug，不如先把“它该干啥”写成几行测试——像列购物清单一样清晰，像对账单一样可验证。