逐行编写匹配类似配置的代码的测试有什么用？
我一直想知道编写与代码一一匹配的测试的用处。
举个例子：在Rails中，你可以在routes.rb中的一行中定义7个restful路由，使用：
resources :products
BDD/TDD规定你先测试，然后编写代码。为了测试这条线的全部效果，开发人员提出了宏，例如 shoulda： http://kconrails.com/2010/01/27/route-testing-with-shoulda-in-ruby-on-rails/
class RoutingTest < ActionController::TestCase
# simple
should_map_resources :products
end
我不是试图挑选编写宏的人，这只是我在 Rails 中看到的模式的一个例子。
我只是想知道它有什么用......最后你只是复制代码，你测试的唯一东西就是 Rails 是否有效。您也可以编写一个工具来将测试宏转换为实际代码......
当我四处询问时，人们回答我：
“测试应该记录你的代码，所以是的，编写它们是有意义的，即使它只是一行对应一行”
你有什么想法？
I have been wondering about the usefulness of writing tests that match code one-by-one.
Just an example: in Rails, you can define 7 restful routes in one line in routes.rb using:
resources :products
BDD/TDD prescribes you test first and then write code. In order to test the full effect of this line, devs come up with macros e.g. for shoulda: http://kconrails.com/2010/01/27/route-testing-with-shoulda-in-ruby-on-rails/
class RoutingTest < ActionController::TestCase
# simple
should_map_resources :products
end
I'm not trying to pick on the guy that wrote the macros, this is just an example of a pattern that I see all over Rails.
I'm just wondering what the use of it is... in the end you're just duplicating code and the only thing you test is that Rails works. You could as well write a tool that transforms your test macros into actual code...
When I ask around, people answer me that:
"the tests should document your code, so yes it makes sense to write them, even if it's just one line corresponding to one line"
What are your thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
对我来说，这是避免犯一些大错误的好习惯。
例如，在合并或编辑后，该资源将被删除。怎么知道呢？
通过此测试，您可以立即看到需要这些资源。如果您想更改或删除它，您需要进行 2 处更改。不只一件事可能会出错。
To me it's a good pratice to avoid some big mistake.
By example after a merge or an editing this resource is delete. How to know that ?
With this test you can see immediatly, that there are this resources needed. If you want change it or delete it you need made 2 changes. Not only one can be do by mistake.
正如我的老板（顺便说一下，他也是一名编码员）所说，这些都是测试的好例子，但有时你只需要知道要测试什么。就您而言，测试 Rails 是否有效是很好的，但众所周知，它已经经过测试。我们不需要为此编写测试。
在我们的开发周期中，我们仅对那些不简单/复杂/尚未测试的事情使用测试。假设您的模型上有一个回形针附件。我们不测试它是否已经连接，回形针人员已经对其进行了测试。您测试的是您的模型是否可以访问该附件或附加该附件的过程或其他内容。
类似的东西:)希望这是有道理的
As my boss(who is also a coder by the way) says, these are fine examples on testing but sometimes you just have to know what to test. In your case, testing that rails works is good, but as we all know, it IS already tested. We don't need to write tests for that.
In our dev cycle, we use tests only for those things that aren't simple/complex/already tested. Say you have a paperclip attachment to a model. We don't test if it's attached already, there's a test for that already made by the paperclip people. What you test is if your model can access that attachment or the process in which you attach it or something.
Something like that :) Hope that makes sense
Rails 已经对其路由 DSL 进行了测试。该宏的唯一好处是它测试您是否实际上已将声明包含在路由文件中，该声明应通过集成测试套件隐式测试。
请记住，添加测试会增加更多需要维护的代码。每次要编写一些代码时，您都应该问自己是否值得花时间来维护/编写测试。然而，当您学习测试优先时，最好严格一些，因为需要时间来了解哪些值得测试，哪些不值得测试。
希望有帮助。
Rails already has tests for its routing DSL. The only benefit of the macro is that it tests whether or not you have actually included the declaration in your route file which should be implicitly tested through integration test suite.
Remember, adding tests adds more code to maintain. Every time you have some code to write you should ask yourself whether it is worth the time that will be involved in maintaining/writing tests or not. When you are learning test-first, however, it is probably better to be strict as it takes time to learn what is worth testing and what isn't.
Hope that helps.
值得深入了解shoulda 宏实际上做了什么。它检查由
resources :products生成的每个路由，即它不仅仅验证resources语句是否存在于路由文件中。所以这实际上并不是一个已经测试过的 Rails 代码的测试实例。It's worth looking under the hood to see what the shoulda macro actually does. It checks each route generated by
resources :products, i.e. it doesn't simply verify that theresourcesstatement exists in the routes file. So this is not really an instance of testing Rails code that has already been tested.我认为你不应该明确地测试类似的东西。
当测试渲染页面时，form_for会抱怨路由不存在。然后我添加它。如果是资源方式或命名路线，在我看来这并不重要。之后，当存在多个命名路由时，您可以重构路由文件，以便使用资源而不是多个命名路由。
I don't think that you should test something like that explicitly.
When a page is rendered in test, form_for will complain that a route does not exist. And then I add it. And if it is the resources way or a named route, that does not matter in my view. Afterwards when there are multiple named routes, you can refactor the routes file so you use resources instead of multiple named routes.
测试不仅仅是帮助您编写更好的代码。您需要确保代码在未来继续工作...回归测试。这就是此类测试所提供的。
There's more to testing than just helping you write better code. You need to make sure that code continues to work in the future... Regression Testing. That's what these kind of tests provide.