需求在变，还要写自动化测试吗？

在询问团队为何不编写自动化测试时，通常有两种答案：系统稳定无变化，或系统变化频繁。对于后者，文章讨论了为何即便需求经常变化，编写自动化测试依然有意义。

软件生命周期中的不断变化是开发者的一大顾虑，因为改动可能造成其他问题。自动化测试是当前最佳实践，它能在代码变更时迅速运行所有测试，增加发布的信心。然而，团队常有误解认为需求变化频繁不适合写自动化测试。

这种认识不足主要有三方面原因。首先，对自动化测试的认识不足，错误地将测试与软件实现紧密耦合，导致测试过时。正确的做法是测试软件行为，这一行为的稳定性较高，除非需求改变。

其次，对需求变化的认识不足。实际上，需求变化常是原需求的补充或改进，而非完全废弃，因此原测试用例通常仍然有效，仅需增加新的测试用例。

最后，对测试的认识存在偏差。测试的目的不是证明系统无Bug，而是揭示系统存在的Bug。自动化测试在回归时能够提醒我们问题，而失败的测试可以驱动我们编写满足需求的代码。

Bob大叔提出测试的FIRST原则中的T代表Timely（及时），即在业务代码实现前编写测试。Test First和测试驱动开发（TDD）基于这一原则，利用测试证明特性未实现，并通过编写业务代码满足需求。