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
对可能会发生变动的代码，不要测试。
