Rails 5 Test Prescriptions 第4章 什么制造了伟大的测试

伴随着程序成长，测试变长，复杂性增加，如何更高效的写测试，对以后开发不会造成麻烦。

测试本身没发被测试，所以一定要清楚，可控。不要加循环，不要过于复杂的自动编程。

Cost and Value 成本和价值。

测试有成本和价值 。因此要最小化成本，最大化价值。

什么是成本，什么是价值？

成本（time）：

• 写测试的时间
• 每次运行测试花费的时间
• 理解测试所需要的时间
• 如果测试出错，搞定它并让程序ok的时间
• 有时候，改变程序代码带来的调整测试所花费的时间

价值(部分)

• 写测试的行为让它更容易的定义代码的结构
• 在集成测试步骤，运行自动化测试快于手动测试
• 测试可以提供有效证据：代码工作正常。
• 如果代码变化了，测试就可以看出来，测试提供了⚠️机制。
• 测试可以帮助开发者更容易的定位bugs

如何写测试节约时间：

• 思考如何让测试失败，而不是成功。如果测试没办法失败，可能不需要这个测试
• 集成测试,integration！留出时间做集成测试
• 对于单元测试，写单元测试关联小的代码变化。使用Mocks and Stubs.
• 尽量避免使用高成本行为，如使用额外的代码库，和数据库的大量对象。在测试中，一个好办法是使用test doubles ，可以避免单元测试用真实的数据依赖。
• 如果发现发一个单一bug让许多测试失败，考虑是否那些测试是有用。如果失败是计划的，考虑失败的那些测试是否在计划中。
• 有时候在开发中有用的测试被之后的测试取代。这些测试可以被删除，或skip，注释。
• 如果要花费好多步骤来写一个单元测试，思考这种可能性：测试在试图告诉你，代码的设计可以被改进以减小依赖性。

Prescription:当写测试时，考虑短期和长期的测试成本。

---

SWIFT: The Five Qualities of Valuable Tests

• Straightforward
• Well defined
• Independent
• Fast
• Truthful

 Straightforward

测试的命名直观-重要。 一目了然的本地创建的数据也有帮助。Factory_Bot有效帮助预备件。

长测试或步骤应当分类。

测试的“”描述，清晰让自己以后debug的时候可以轻松理解。

不要用loop,如果必须检验，可以抽几个重要的hash对儿，统一放在一个it中。

Well Defined 

如果反复运行相同的测试得出统一的结果，这个测试则被定义的很好。

三个典型的重复问题是：

• time and date testing
• random numbers
• third-party or Ajax calls

关键的解决办法是：让测试数据可复制的，一致的。使用封装和test doubles。

第14章讨论测试第三方服务， 7章讨论test doubles

Independent

如果不依靠其他测试或额外数据，一个测试就是独立的。这样可以限定测试失败的范围。易于dubug。

影响独立性的最大障碍是使用全局数据。

第15章讲解Troubleshooing 和debug

Fast 

长测试会延长测试速度，作者见过30分钟的测试。

让测试变慢的几个重要原因：

• 开始时间？
• 代码中的依赖，在测试中需要创建大量对象来使用方法。
• 过度的使用数据库或者额外的第三方服务

加速的办法是隔绝Rails stack的应用逻辑。可以不加载整个raisl来提速。或者不从数据库检索数据。

第6章，16章涉及相关。

Truthful 

对可能会发生变动的代码，不要测试。