logo标签列表

如何在现有的Rails项目中添加测试？

ruby-on-railsrubytesting
17

我有一个Rails项目，没有为其构建测试（太丢人了！），代码库变得非常庞大。我的一个朋友说，除非从一开始就使用它，否则使用RSpec会很痛苦。这是真的吗？他为什么这么说？

考虑到现有的测试套件和代码库已经存在，针对这个问题，我该采取什么最佳行动方案才能让它可测试？与从一开始做有多大不同？

这是更广泛的问题的变体 --> https://dev59.com/a3VD5IYBdhLWcg3wDHDm - rpattabi
6个回答
23

最近在 RSpec 邮件列表上有一个问题提出来了，我们通常给出的建议是：

  • 不要试图为现有的工作代码添加规范，除非你打算更改它-这很费力，并且除非需要更改代码，否则毫无意义。
  • 从现在开始为任何更改编写规范。修复错误是这样做的一个特别好的机会。
  • 尝试培养自己的纪律，在触及代码之前，首先编写一个失败的示例（=规范）来驱动变化。

您可能会发现，没有通过代码示例或单元测试驱动的代码设计使得编写测试或规范变得困难。这也许就是你的朋友所指的。你几乎肯定需要学习一些关键的重构技术，以打破依赖性，以便你可以从你的规范中独立地练习每个类。Michael Feathers 的优秀著作《与遗留代码有效地工作》有一些很棒的材料可以帮助你学习这项微妙的技能。

我还鼓励您使用内置的 spec:rcov rake 任务生成代码覆盖率统计数据。当您开始对代码库进行测试时，看到这些数字上升是非常有成就感的。

为什么不要测试？建议从高级别测试开始听起来非常适用... - carl crott
3
也许可以从模型开始？它们应该可以被孤立地测试，这应该是最容易的部分。
然后选择一个模型并开始编写测试来说明它的功能。在进行测试时，考虑其他测试代码的方式 - 是否有一些边缘情况可能不确定？编写测试并查看模型的行为。随着测试的开发，您可能会看到代码中存在不够干净和未去重复（DRY）的区域。现在你有了测试，你可以重构代码，因为你知道你不会影响行为。尽量不要在没有测试的情况下开始改进设计 - 这样会导致疯狂。
一旦您确定了模型，就可以向上移动。
这是一种方法。另一种方法可能是从视图或控制器开始，但您可能会发现，从端到端的交易测试开始，逐渐将其拆分成更小的部分会更容易。
2
接受的答案是很好的建议 - 虽然在某些情况下不实用。最近，我在我的几个应用程序中遇到了这个问题，因为我需要测试现有代码。简单地说，没有其他办法。
我开始做所有的单元测试，然后转向功能测试。
养成编写任何新代码或每当您要更改系统部分时编写失败测试的习惯。我发现这帮助我在进行测试方面获得更多知识。
使用rcov来衡量您的进展。
祝你好运！
问题在于，如果没有“失败优先”测试，你无法证明你的代码实际上是有效的（例如符合规范）。 - Ariejan
是的，你可以。如果你有一个构建想法，你就可以形成一个测试需求的想法。然后与测试一起工作，直到它足够好。但我认为任何测试都比没有测试要好。 - E.E.33
2

编写现有代码的测试可能会揭示代码中的错误。这些测试将迫使您查看现有代码，以便您可以看到需要编写哪些测试才能使其通过，并且您可能会发现一些可能可以更好地编写的代码或现在无用的代码。

另一个提示是在遇到错误时编写测试，以便它永远不会再次出现，这称为回归测试。

1

改装规格并不一定是一个坏主意。你从工作代码到具有已知属性的工作代码，这使你能够了解任何未来的更改是否会破坏任何东西。目前，如果您需要进行更改，您如何知道它会影响什么？

当人们说很难向现有代码添加测试/规格时，他们的意思是难以测试的代码通常高度耦合，这使得编写低级别隔离测试变得困难。

一个想法是使用类似于RSpec故事运行器的全栈测试开始。然后，您可以从“外部”开始，在低级别隔离测试中隔离您可以的内容，并逐步逐个解开更难的代码。

-1
你可以开始编写“特征测试”。有了这个，您可能想尝试自命不凡的 gem here：
虽然它仍然是一个正在进行中的工作。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接