我读过的一切只是显示测试验证. rails中的验证是否不应该正常工作？它似乎更像是测试框架,而不是测试你的代码.为什么需要测试验证？
此外,测试似乎对您的代码的任何更改都非常脆弱.所以,如果你改变任何模型,你必须改变你的测试和灯具匹配.这不违反DRY原则吗？
第三,编写测试代码似乎需要很多时间.是正常吗刷新我的浏览器是否更快,看看它是否有效？我已经不得不使用我的应用程序来查看它是否正确流动,并确保我的CSS没有爆炸.为什么手动测试不够用？
我以前问过这些问题,我没有比“自动测试自动化”更多.我足够聪明,以了解自动化任务的优点.我的问题是写作测试的成本与好处相比似乎是荒谬的.也就是说,任何详细的回应都是值得欢迎的,因为我可能错过了一两个好处.
解决方法
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代码库中有单元测试来确保它.当您测试模型的验证时,您正在测试验证的具体细节：长度,接受的值等.您确定代码是按照预期编写的.一些验证是简单的帮助者,您可以选择不对“没有人可以弄乱validate_numericality_of呼叫”的概念进行测试.真的吗？每个开发人员总是记得首先写它吗？每个开发人员都不会意外删除一个坏的副本贴上的一行吗？在我个人看来,您不需要测试Rails验证帮助者的最后一个值组合,但是您需要一行来测试它的正确值,以防将来某些朋克更改它没有适当的预想.
此外,其他验证更复杂,需要大量自定义代码 – 他们可能需要更彻底的测试.
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.他们正在沟通(这就是编程,沟通)两个截然不同的事情.测试说代码应该做一些事情.代码说它实际上是什么.当这些事情断开连接时,测试是非常重要的.
显然,测试代码和应用代码密切相关.我认为他们是一个硬币的两面.你不会想要一个没有背部的前面,或者没有前面的背面.良好的测试代码强化了良好的应用代码,反之亦然.两者一起用于了解您正在尝试解决的整个问题.并且写得很好的测试代码是文档 – 它显示了应该如何使用应用程序代码.
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服务,第三方库,多个数据库,几个月的开发和需求变更等,还有很多其他因素在发挥.手动测试根本不够.在一个真正复杂的项目中,一个地方的变化往往会在其他地方产生不可预见的结果.正确的架构有助于缓解这个问题,但通过识别一个地方的变化何时破坏另一个地方,自动化测试也可以帮助(并帮助确定架构可以改进的点).
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.
我会列出更多的好处.
如果你先测试(测试驱动开发),你的代码可能会更好.我没有遇到一个程序员谁给了一个坚实的镜头,谁不是这样的情况.测试首先迫使您考虑问题,并实际设计您的解决方案,而不是将其解决.此外,它强制您了解问题域足够好,如果您必须将其删除,您知道您的代码在您定义的限制内工作.
如果您有完整的测试覆盖范围,您可以重构没有风险.如果软件问题非常复杂(再次,持续数月的现实世界项目往往会变得复杂),那么您可能希望简化以前写过的代码.所以,你可以编写新的代码来替换旧的代码,如果它通过了所有的测试,你就完成了.它完全符合旧代码对测试的做法.对于计划使用敏捷开发方法的项目,重构是绝对必要的.总是需要做出改变.
总而言之,自动化测试尤其是测试驱动开发基本上是一种管理软件开发复杂性的方法.如果您的项目不是很复杂,成本可能会超过利益(尽管我怀疑).然而,现实世界的项目往往是非常复杂的,测试和TDD的结果本身就是：他们工作.
(如果你好奇,我发现Dan North的行为驱动开发文章对于了解很多测试值非常有帮助：http://dannorth.net/introducing-bdd)
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。