Ruby on Rails - 为什么要使用测试? [英] Ruby on Rails - Why use tests?

问题描述

我对 Ruby on Rails 中的各种测试设备的用途感到困惑.我已经使用该框架大约 6 个月了，但我从未理解它的测试部分.我使用过的唯一测试是 Java 中的 JUnit3，而且只是简短的.

I'm confused about what the various testing appliances in Ruby on Rails are for. I have been using the framework for about 6 months but I've never understood the testing part of it. The only testing I've used is JUnit3 in Java and that only briefly.

我读过的关于它的一切都只是显示了测试验证.rails 中的验证不应该起作用吗?看起来更像是测试框架而不是测试您的代码.为什么需要测试验证?

Everything I've read about it just shows testing validations. Shouldn't the validations in rails just work? It seems more like testing the framework than testing the your code. Why would you need to test validations?

此外，测试对于代码中的任何更改似乎都非常脆弱.因此，如果您更改模型中的任何内容，则必须更改测试和装置以匹配.这不是违反了 DRY 原则吗?

Furthermore, the tests seem super fragile to any change in your code. So if you change anything in your models, you have to change your tests and fixtures to match. Doesn't this violate the DRY principle?

第三，编写测试代码似乎需要很多时间.这是正常的吗?刷新我的浏览器并查看它是否有效不是更快吗?我已经不得不使用我的应用程序来查看它是否正确流动并确保我的 CSS 没有爆炸.为什么手动测试还不够?

Third, writing test code seems to take alot of time. Is that normal? Wouldn't it just be faster to refresh my browser and see if it worked? I already have to play with my application just to see if it flows correctly and make sure my CSS hasn't exploded. Why wouldn't manual testing be enough?

我以前问过这些问题，但我得到的只是自动化测试是自动化的".我足够聪明，可以找出自动化任务的优势.我的问题是，与收益相比，编写测试的成本似乎高得离谱.也就是说，欢迎任何详细的回复，因为我可能错过了一两个好处.

I've asked these questions before and I haven't gotten more than "automated testing is automated". I am smart enough to figure out the advantages of automating a task. My problem is that costs of writing tests seem absurdly high compared to the benefits. That said, any detailed response is welcome because I probably missed a benefit or two.

推荐答案

不应该rails 中的验证是否有效?它似乎更像是测试框架而不是测试你的代码.为什么会您需要测试验证吗?

Shouldn't the validations in rails just work? It seems more like testing the framework than testing the your code. Why would you need to test validations?

Rails 中的验证确实有效——事实上，Rails 代码库中有单元测试来确保它.当您测试模型的验证时，您正在测试验证的细节:长度、接受的值等.您要确保代码按预期编写.一些验证是简单的助手，您可以选择不根据没有人可以搞砸 validates_numericality_of 调用"的概念来测试它们.真的吗?是不是每个开发人员都记得一开始就写它?每个开发人员都不会意外删除错误复制粘贴上的一行吗?在我个人看来，您不需要测试 Rails 验证助手的每一个值的最后组合，但是您需要一行来测试它是否存在并传递了正确的值，以防万一一些朋克在将来改变它没有适当的深谋远虑.

The validations in Rails do work -- in fact, there are unit tests in the Rails codebase to ensure it. When you test a model's validation, you're testing the specifics of the validation: the length, the accepted values, etc. You're making sure the code was written as intended. Some validations are simple helpers and you may opt not to test them on the notion that "no one can mess up a validates_numericality_of call." Is that true? Does every developer always remember to write it in the first place? Does every developer never accidentally delete a line on a bad copy paste? In my personal opinion, you don't need to test every last combination of values for a Rails' validation helper, but you need a line to test that it's there with the right values passed, just in case some punk changes it in the future without proper forethought.

此外，其他验证更复杂，需要大量自定义代码——它们可能需要更彻底的测试.

Further, other validations are more complex, requiring lots of custom code -- they may warrant more thorough testing.

此外，这些测试看起来超级棒对代码中的任何更改都很脆弱.所以如果您更改模型中的任何内容，你必须改变你的测试和要匹配的固定装置.这不是违反了 DRY 原则?

Furthermore, the tests seem super fragile to any change in your code. So if you change anything in your models, you have to change your tests and fixtures to match. Doesn't this violate the DRY principle?

我不认为它违反了 DRY.他们在交流(这就是编程，交流)两种截然不同的东西.测试表明代码应该做点什么.代码说明了它实际的作用.当这些事情之间存在脱节时，测试就非常重要.

I don't believe it violates DRY. They're communicating (that's what programming is, communication) two very different things. The test says the code should do something. The code says what it actually does. Testing is extremely important when there is a disconnect between those things.

显然，测试代码和应用程​​序代码是紧密相连的.我认为它们是硬币的两个面.你不会想要没有背部的前部，或者没有前部的背部.好的测试代码会加强好的应用程序代码，反之亦然.两者一起用于理解您要解决的整个问题.而且编写好的测试代码就是文档——它展示了应用程序代码应该如何使用.

Test code and application code are intimately linked, obviously. I think of them as two sides of a coin. You wouldn't want a front without a back, or a back without a front. Good test code reinforces good application code, and vice versa. The two together are used to understand the whole problem that you're trying to solve. And well written test code is documentation -- it shows how the application code should be used.

第三，编写测试代码似乎需要很多时间.这是正常的吗?不会只是刷新我的更快浏览器，看看它是否有效?一世已经要和我一起玩了申请只是为了看看它是否流动正确并确保我的 CSS 没有爆炸了.为什么不手动测试够了吗?

Third, writing test code seems to take alot of time. Is that normal? Wouldn't it just be faster to refresh my browser and see if it worked? I already have to play with my application just to see if it flows correctly and make sure my CSS hasn't exploded. Why wouldn't manual testing be enough?

您只参与过非常小的项目，对于这些项目来说，测试可以说是足够了.但是，当您与多个开发人员、数千或数万行代码、与 Web 服务的集成点、第三方库、多个数据库、数月的开发和需求更改等一起工作时，还有很多其他的因素在起作用.手动测试是不够的.在任何真正复杂的项目中，一个地方的变化往往会对其他地方产生不可预见的结果.适当的架构有助于缓解这个问题，但自动化测试也有助于(并有助于确定架构可以改进的点)，方法是识别一个地方的更改何时破坏另一个.

You've only worked on very small projects, for which that testing is arguably sufficient. However, when you work on a project with several developers, thousands or tens of thousands of lines of code, integration points with web services, third party libraries, multiple databases, months of development and requirements changes, etc, there are a lot of other factors in play. Manual testing is simply not enough. In a project of any real complexity, changes in one place can often have unforeseen results in others. Proper architecture helps mitigate this problem, but automated testing helps as well (and helps identify points where the architecture can be improved) by identifying when a change in one place breaks another.

我的问题是编写测试的成本似乎很荒谬与福利相比高.那说，欢迎任何详细的回应因为我可能错过了福利或两个.

My problem is that costs of writing tests seem absurdly high compared to the benefits. That said, any detailed response is welcome because I probably missed a benefit or two.

我将列出更多好处.

如果您先进行测试(测试驱动开发)，您的代码可能会更好.我还没有遇到过一个给它一个可靠的机会的程序员，但情况并非如此.测试首先迫使您考虑问题并实际设计您的解决方案，而不是将其破解.此外，它迫使您充分了解问题域，以便在您必须破解它时知道您的代码在您定义的限制范围内工作.

If you test first (Test Driven Development) your code will probably be better. I haven't met a programmer who gave it a solid shot for whom this wasn't the case. Testing first forces you to think about the problem and actually design your solution, versus hacking it out. Further, it forces you to understand the problem domain well enough to where if you do have to hack it out, you know your code works within the limitations you've defined.

如果您有完整的测试覆盖率，则可以无风险地进行重构.如果软件问题非常复杂(同样，持续数月的实际项目往往很复杂)，那么您可能希望简化以前编写的代码.因此，您可以编写新代码来替换旧代码，如果它通过了所有测试，您就大功告成了.它完全按照旧代码在测试方面所做的工作.对于一个计划使用敏捷开发方法的项目，重构是绝对必要的.总是需要做出改变.

If you have full test coverage, you can refactor with NO RISK. If a software problem is very complicated (again, real world projects that last for months tend to be complicated) then you may wish to simplify code that has previously been written. So, you can write new code to replace the old code, and if it passes all of your tests, you're done. It does exactly what the old code did with respect to the tests. For a project that plans to use an agile development method, refactoring is absolutely essential. Changes will always need to be made.

总而言之，自动化测试，尤其是测试驱动开发，基本上是一种管理软件开发复杂性的方法.如果您的项目不是很复杂，成本可能会超过收益(尽管我对此表示怀疑).然而，现实世界的项目往往非常复杂，测试和 TDD 的结果不言自明:它们有效.

To sum up, automated testing, especially test driven development, is basically a method of managing the complexity of software development. If your project isn't very complex, the cost may outweigh the benefits (although I doubt it). However, real world projects tend to be very complex, and the results of testing and TDD speak for themselves: they work.

(如果你好奇，我发现 Dan North 的关于行为驱动开发的文章对理解测试中的很多价值非常有帮助:http://dannorth.net/introducing-bdd)

(If you're curious, I find Dan North's article on Behavior Driven Development to be very helpful in understanding a lot of the value in testing: http://dannorth.net/introducing-bdd)

这篇关于Ruby on Rails - 为什么要使用测试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！