"Google Testing on the Toilet(TotT)"系列文章，是 Google Test Engineers 为了激发开发人员写出更好的测试代码。Google Test Engineers 写了从依赖注入到代码覆盖率相关很多的测试科普文章，定期将这些测试科普文章粘贴到 Google 遍布全球差不多 500 座的卫生间中。
最初聚焦在测试，TotT 现在已经包括很多的技术话题，比如写简洁代码的诀窍和避免出现安全 bug 的方法。
端对端测试会从一个端到另一个端，测试你的整个系统，不同端之间处理任何数据都认为是一个黑盒。端对端测试能找到贯穿你整个系统的 bugs。除了单元测试和集成测试，端对端测试是一个检验测试健壮的关键部分，因为在近似生产环境下，对你的系统质量有足够的信心。不幸的是，端对端测试相比单元测试或集成测试速度更慢，更不可靠和维护成本更高。需认真考虑端对端测试是否值得，如果觉得值得，那么怎么写最佳的端对端测试呢？
让我们来思考下面的"登入流程"，怎样去构造端对端测试
为了获得更有效的成本，端对端测试应该关注你系统的整体，而不是用更细粒度的测试进行评估，比如资源分配，一致性和 API 兼容。更具体的说：
对每一个重点的用例，都应该有对应的一个端对端测试。对每个重要类型的错误应该包含一个用例。这样做的目标是保持你整个端对端测试数量在一个低位。
每次测试分配至少一周的四分之一时间去保证你的端对端测试的稳定性，解决的问题如下：速度慢和不可靠的依赖或细小的 UI 改动。
聚焦你的精力在验证整个系统的行为上，而不是具体的实现细节；举个例子，当测试登入行为，验证登入成功，而不是具体的信息或者视觉布局，它们可能经常改动。
通过提供概述级别的日志文件，记录通用的测试失败模式和保存所有相关系统状态信息（比如：截屏，数据库的快照等等）使你的端对端测试容易调试。
端对端测试也伴随着一些重要的注意事项：
属于其他部门的系统组件可能在你不知道的情况下被改动，导致你无法测试。这提高了你整体的维护成本，但是能突出不兼容的改动。
很难构建一个完全封闭的端对端测试；遗留的测试数据可能会影响到将来的测试或生产系统。尽量把你的测试数据清理干净。
端对端测试常常需要多元性测试 (fakes or stubs)，因为存在潜在的依赖；无论如何，他们有很高维护成本，因为它们随着时间增长，越来越偏离真实的实现。
原作者：Adam Bender
译者：胡刚
原文链接：https://testing.googleblog.com/2016/09/testing-on-toilet-what-makes-good-end.html
