在测试自动化项目中使用 Ruby 是否不安全？ [关闭]答案

【问题标题】：Is Ruby unsafe to use on Test Automation Projects? [closed]在测试自动化项目中使用 Ruby 是否不安全？ [关闭]
【发布时间】：2017-01-25 09:33:37
【问题描述】：

我在 Appium、Frank、EggPlant、Xamarin、Xcode UITesting 和 Xcode UIAutomation 上做了很多移动自动化。最近，第三方开始为 Ruby 提供 Calabash 脚本。我开始看这个选项，发现了以下文章： http://qualitytesting.tumblr.com/post/156318324159/ruby-projects

我特别被文章中的以下 cmets 所吸引：

Ruby 最大的问题是它可能被滥用。我认为在将其用作测试框架语言时，这是一个特别普遍的问题，因为许多测试人员没有接受过任何正式的编程培训，而且通常不了解面向对象的原则或可维护的架构模式。测试人员通常是根据他们的边缘案例能力而不是他们的编程能力而被雇用的，并且经常被招聘经理雇用而没有足够的编程知识来评估他们的编程能力，因此使用 Ruby 是如此危险。

还有这个部分：

Ruby 缺乏规则的麻烦在于它是一种解释型语言。在你运行它之前你真的不知道它是否有效，这很费力 - 与编译语言相比，反馈循环非常慢。即使它运行，它也不一定做任何事情。 IDE 可以帮助您并预先为您提供语法错误，但是由于对语言使用的限制如此宽松，因此滥用和意大利面条式代码的可能性是无穷无尽的。

最后：

Ruby 中没有协议/合约/承诺。无法保证您认为是字符串的 var 实际上不是数组或任何其他类型的对象。考虑到在文化上，测试人员的编程标准通常比开发人员低，而且他们的代码通常不那么认真，并且比生产环境低代码。文化可能是造成这种情况的罪魁祸首，但这仍然是一个问题。将此添加到您的企业对 UI 测试价值的任何担忧中；使用 Ruby 或 Python 是进一步破坏和贬低 UI 测试的好方法

然后文章建议坚持使用 ruby 编写脚本而不是大型项目。由于测试自动化通常会像它的大小一样成为项目，这可能是一个问题。

所以我的问题是，Ruby 是一种用于测试自动化的危险语言吗？我坚持使用更多静态类型的语言是否更安全？还是 Ruby 很好用，而这篇文章没有抓住重点？

【问题讨论】：

这篇文章的全部内容是，为重要项目雇用没有经验的编码员是很危险的。使用 C# 或 Java 可以很好地编译和运行测试，但仍然不能测试任何东西。
我认为如果你的开发人员不那么严格的话，与强类型语言相比，使用 ruby 更容易得到意大利面条代码。我的主要担心（今天早上已经阅读了更多内容）实际上是缺乏从强类型语言（使用像 xcode/ellipse/android studio 之类的 IDE）中获得的全面智能感知优势。使用页面对象模式，我喜欢能够拥有一个页面对象的实例，然后键入“点”并查看可以执行的所有操作。 Ruby IDE 能否提供此功能（Rubymine 可能提供但程度有限）？
* 静态类型（非强类型）
这篇文章只是 FUD。我已经在静态类型世界和动态世界中进行了编程，并且它们都可以正常工作如果程序员有任何好处。没有任何语言可以拯救一个糟糕的程序员。
我的“恐惧”是很多人似乎都有这种对动态类型语言的恐惧，例如：stackoverflow.com/questions/42934/…

标签： ruby automated-tests ui-automation calabash strong-typing

【解决方案1】：

这只是该作者的意见。他说

Ruby 有可能被滥用
测试人员没有接受过任何正式的编程培训
Ruby 是一种解释型语言，因此速度较慢
Ruby 存在误用和意大利面条式代码的可能性
弱打字是不好的

潜力：是的，任何语言都应该关注滥用问题

Spagetti 代码可以用任何语言编写，但很少有语言能像 Ruby 一样简洁、优雅和精致，同时它是我所知道的最易读的语言。

我最近阅读了 this 关于 Ruby 单元测试的博文，其中指出“测试很重要……并且有意见”，这说明了一切。

This 的博客也很有趣，它指出 Ruby 中的单元测试优于 Java 中的接口。

在我看来，Ruby 是最鼓励和使用单元测试的语言之一。静态类型是为了让编译器高兴，动态类型是为了让开发者高兴，这是我从某个地方学来的一句话，关于这个主题的书都有写，每个人都有自己的观点，所以不再赘述。

Ruby 并不慢，首先，编写代码的时间大大低于编译语言，恕我直言，编译语言在大多数情况下比在几秒钟内执行的脚本和返回的网页的执行时间更重要以微秒为单位。解释语言的执行速度比编译语言慢：没错，但是一旦需要更高的速度，您可以通过 gems 或微服务调用编译的东西。如果您达到 100 万用户上限，您就有更多资源可以使用，许多大型 Web 服务开始使用 Ruby 和 Rails，并随着需求的增加转向其他语言来提供部分服务。

在我的组织中，我们都使用 Ruby 和 Java，Ruby 非常适合自动化脚本、系统管理、临时解决方案、需要大量更改和配置的脚本、小型 Web 应用程序以及一般与 Web 的交互。开发人员自己进行测试。使用敏捷和 Scrum 方法。

Java 用于长期开发、更大的团队，这些开发人员经常使用少量测试和老式瀑布方法。

开发人员通常在第一个方面很好，在第二个方面很差，反之亦然。

所以这一切都取决于并且非常自以为是，我会说继续尝试并提出自己的意见。

【讨论】：

我认为这篇文章更多的是围绕 UI 自动化测试而不是单元测试。你知道 ruby 在 UI 自动化测试中的表现如何吗？
注意：Ruby 是强类型。
我的错……我的意思是静态类型。（抱歉，今天早上对 ruby 与其他语言进行了太多研究。大脑越来越痛）。
@CharlieSeligman 是的，它经常用于此目的，我在 EricDuminil 想到了 watir 和 selenium，是的，你说得对，我的意思是静态动态，在答案中进行了调整，谢谢
经过大量调查后，我想我会离开 Ruby（和其他动态类型语言）......认为我只是一个彻头彻尾的静态（一些参考：blog.jooq.org/2014/12/11/…stackoverflow.com/questions/125367/…@987654325 @softwareengineering.stackexchange.com/questions/16/…

【解决方案2】：

我意识到我对 ruby 是否适合大型自动化项目的困惑实际上是更广泛的动态与静态类型辩论的一部分。真的 Ruby 可以被 JavaScript 等取代。

由于 Head First 专家在下面的视频中提到的原因，我决定坚持使用静态类型语言进行 UI 自动化测试，因为动态类型语言（如 JavaScript 和 Ruby）具有灵活性的优势，但也灵活性的风险：

https://www.youtube.com/watch?v=lPuQkC6HRPk

Calabash-Ruby 组合在测试自动化领域变得流行（可能是因为如果您是编码新手，学习 Ruby 很容易）。我意识到这个答案可能会被低估，因为它认为 Calabash-Ruby duo 不是大型自动化测试项目的首选。这只是我的观点，其他人可能不同意。如果您投反对票，请留下 cmets 的原因，以便我们希望进一步教育辩论。如果它是一个明智的选择（而不仅仅是最简单的选择），我绝对愿意接受 calabash-ruby。

【讨论】：

你不能比较 Ruby 和 Javascript。它们都是动态的，但是 Javascript 是弱类型的，而 Ruby 是强类型的。如果您尝试计算1 + '1'，Ruby 将引发异常，Javascript 将愉快地返回"11"。对于1 - '1'，JS 返回0。这使得很难找到错误恕我直言。
同意 JavaScript 更危险，但动态语言在编译时仍然会遗漏很多东西，而且似乎也不适合页面对象设计模式。
看来您已经下定决心：Ruby 不适合您和您的需求，这种方式完全没问题！但这并不意味着用 Ruby 编写干净、高效、完整和可读的测试是不可能的。
完全同意 Eric - 干净、高效、完整和可读的测试在 Ruby 中是可能的。我认为这只是静态与动态的偏好，在今天研究了很多之后，我认为我更像是一个静态的人:-)