适当的测试能够覆盖掉一些底层库升级带来的bug，还是值得的，一个系统上了生产后，不可能不写测试，因为我就有过不写测试的系统上生产的经验，一个rb文件的语法错也会导致生产挂掉，显然也不可接受。至于需要写多少测试来保证生产的稳定性，这其实是一个业务代价问题。
我喜欢 TDD 创始人 Kent Beck 的回答（ https://stackoverflow.com/a/153565/518291 ）： 我因有效的代码而不是测试而获得报酬，所以我的理念是尽可能少地测试以达到给定的置信度（我怀疑这种置信度与行业标准相比很高，但这可能只是狂妄自大） . 如果我通常不会犯某种错误（比如在构造函数中设置错误的变量），我就不会对其进行测试。我确实倾向于理解测试错误，所以当我有复杂条件的逻辑时，我会格外小心。在团队中编写代码时，我会修改我的策略以仔细测试我们共同容易出错的代码。 基于这种理念，不同的人会有不同的测试策略，但考虑到对测试如何最好地适应编码的内部循环的理解尚不成熟，这对我来说似乎是合理的。十年或二十年后，我们可能会有一个更通用的理论来说明哪些测试要写，哪些测试不要写，以及如何区分。与此同时，实验似乎是有序的。 我发现我也是按这种策略写测试的，如果哪里逻辑很简单，可能不会写测试，而复杂的地方尽可能高的覆盖测试。
适当的测试能够覆盖掉一些底层库升级带来的bug，还是值得的，一个系统上了生产后，不可能不写测试，因为我就有过不写测试的系统上生产的经验，一个rb文件的语法错也会导致生产挂掉，显然也不可接受。至于需要写多少测试来保证生产的稳定性，这其实是一个业务代价问题。
我喜欢 TDD 创始人 Kent Beck 的回答（ https://stackoverflow.com/a/153565/518291 ）：
我发现我也是按这种策略写测试的，如果哪里逻辑很简单，可能不会写测试，而复杂的地方尽可能高的覆盖测试。