每个实行持续交付的项目，都有生产流水线的元素，如持续集成和自动化测试。这些测试是在不同层面进行的，从单元测试到冒烟测试再到功能测试。自动化功能测试的优点之一是可重复性和可预测的执行时间。出于这个原因，它应该作为软件质量的每一个构建之后的指标。功能测试自动化往往会成为一个瓶颈，所以你应该熟悉一下如何创建这样的测试的基本原则。
首先设计你的测试
测试集合可以比作盆景树。
最初的时候，我们照顾树根和树干。我们选择会成长的主要分支，我们每天都细心照料这棵树并等待它长出健康的叶子。
我们可以以类似的方式继续测试。
我们建一个将负责应用程序主要功能（例如：开启）的基类。
根据说明，我们先明确将被测试覆盖的应用程序的主要功能，然后每天我们在执行测试的时候都添加更多平行测试。
每一个支持测试（例如创建一个新的用户）的方法都需要与测试分离——让我们在单独的类里面来实现。
你应该在包括了应用程序主要功能的目录里保持类。
去建一个规定很多功能共有方法的抽象类是很好的做法。
如果你正在测试Web应用程序，就用页面对象设计模式。该模式里，一个类及其方法对应了单个页面的功能或一个大型网页里单个页面上的一个元素。
无需事事自动化
自动化花费很多，所以你应该主要测试应用程序的主要功能。
某些测试可以快速轻松地手动完成，且潜在脚本可能难以实现。
值得用到自动化的是那些繁琐的需要被重复很多次的，和那些需要大量数据验证的测试工作。
写短测试
在一个或多个测试失败的情况下，开发团队的任何成员都应该能够轻松地找到错误的原因。
出于这个原因，每个测试方法里应该最多有5个断言，并且每个方法都必须提供的测试操作的完整记录。
明智的做法是使用BDD（行为驱动开发）技术，但是当你没有用一个特定的测试框架时，你应该把接下来的测试步骤放在comments //given //when //then下。
创建独立测试
在测试类中的每个方法应该是一个独立的实体，而不是依赖于其他测试。我们应该能够在任何时间运行单个测试。否则，这样的测试用例集将来维护起来就会很贵——必须定期跟踪和更新测试之间的联系。
很多时候，测试需要一定的前提条件来满足。这些条件不应该用外部方法，应该在试验开始时运行。如果这些条件和测试类的所有方法一样，它们就可以被放在一开始进行的方法里（例如：在JUnit中被标记为@ BeforeClass）。
关注可读性
源代码应该是自我记录的，而写下以下几行代码的每个利益相关者应该明白测试在做什么，为什么它被这么写。尽量避免在源代码注释，因为它也必须被更新。这值得花比平常多一点的时间来命名方法，从而使你的代码更易读。
再看看行为驱动开发技术，每个测试方法都应以单词“应该”开始，而不是“测试”。
根据这一惯例，我们马上就可以明白一个特定的方法测试什么内容了，它在分析测试报告时特别有用。
