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

    当问一个团队为什么不写自动化测试的时候，往往有两种答案。一是我们的系统已经没什么变化，写测试没意义；另一个是我们系统经常变，写测试没意义。对于第一种情况，如果系统真的不变，确实补一些自动化测试没什么意义。今天我们说一下第二种情况。

    软件在其生命周期内是不断变化的。唯一的不变就是变化。否则我们就不叫软件，而是硬件。软件变化是每个开发者恐惧的，因为我们不知道这次改变是否破坏了其他东西。为了消除这个恐惧，当前最佳实践是有足够的自动化测试。这样我们可以在代码变更的时候用较短时间运行所有自动化测试。这样会增加我们发布的信心。但为什么会产生“我们的需求经常变，所以我们没法写自动化测试”的认知呢？

    一是对自动化测试的认识不足。比如对单元测试，到底什么是单元？有些会试图去为每一个方法、每一个类编写测试。这种测试就是在测试软件的实现方式。根据实现编写自动化测试，就是把测试和实现紧紧耦合了，而软件的实现方式随着需求的变化是可能不断调整的。于是之前写的测试就很容易过时，这时可能要删除重新写。所以这时候会觉得编写单元测试就是累赘，起不到作用。而正确的方式应该是测试软件的行为而不是实现。而行为的稳定性就高多了，除非需求变了，行为才会改变。

    二是对需求变化的认识不足。在实际开发中，需求的变化有几种：原需求废弃改成新需求、原需求增加新特性。对于第一种情况，实际上是比较少发生的。发生较多的是对原需求的补充、改进。在这种情况下，如果你测试的是行为，由于原来的需求场景并没有被废弃，所以原来的测试用例依然是成立的，就是需要增加新的测试用例。比如我们做一个登录的功能，一开始有个密码正确、密码错误的测试用例，后面增加了新需求：密码错误三次锁定账户。这时候原来的测试用例并没有废弃，最多需要稍微调整下。有这种认知可能是原来写的测试过大，一个测试包含了多种场景，如果一个测试包含的场景太多，确实会出现经常要改的情况。而在正确的实践下，我们确实在不断改需求，但原测试很少会废弃。

    三是对测试认识的偏差。测试不是来告诉我们系统没有Bug，而是告诉我们系统有Bug。当我们已经人肉测试完没有找到Bug，这时候加上自动化测试有什么意义呢？一个永远不会失败的测试什么也不会告诉我们。最多也就是将来改出问题了在回归的时候可以提醒我们。而一个失败的测试可以告诉我们某个需求还没有被满足，从而驱动我们去编写代码满足需求。

    Bob大叔提出写测试的FIRST原则。T就是Timely。多及时算及时呢？就是在业务代码还没有实现的时候就编写。这时候我们可以用测试来证明这个特性我们还没做，而当我们编写业务代码让测试通过了，我们的需求就被满足了。这称之为Test First。而测试驱动开发（TDD）正是基于这样的思想建立的工程实践。