我在Appium，Frank，EggPlant，Xamarin，Xcode UITesting和Xcode UIAutomation上做了大量的移动自动化。最近，第三方开始向Ruby提供Calabash脚本。我开始查看此选项并找到以下文章： http://qualitytesting.tumblr.com/post/156318324159/ruby-projects
我特别关注文章中的以下评论：
Ruby最大的问题是它可能被滥用。我认为当将它用作测试框架语言时，这是一个特别令人难以置信的问题，因为许多测试人员没有任何正式的编程培训，并且通常不了解面向对象的原则或可维护的架构模式。测试人员经常受雇于他们的边缘案例能力，而不是他们的编程能力，并且经常由招聘经理聘用而没有足够的编程知识来评估他们的编程能力，因此使用Ruby是如此危险。
本节：
Ruby缺乏规则的麻烦因为它是一种解释性语言而更加复杂。你真的不知道它是否有效，直到你运行它，这是费力的 - 反馈循环与编译语言相比非常慢。即使它运行，它也不一定做任何事情。 IDE可以帮助您，并提前给您语法错误，但由于对语言的使用有如此宽松的限制，滥用和意大利面条代码的可能性是无止境的。
最后：
Ruby中没有协议/合同/承诺。无法保证您认为是字符串的var实际上不是数组或任何其他类型的对象。将测试人员放在没有背部的框架上是危险的，考虑到文化方面，测试人员通常认为编程标准低于开发人员，他们的代码通常不那么重视并且保持在比生产更低的标准码。文化可能是这个问题的罪魁祸首，但它仍然是一个问题。将此添加到您的企业对UI测试价值的任何担忧;使用Ruby或Python是进一步破坏和降低UI测试的好方法
然后文章建议坚持使用ruby脚本而不是大型项目。由于测试自动化通常会像其大小一样变成项目，因此这可能是一个问题。
所以我的问题是，Ruby是一种用于测试自动化的危险语言，我是否更安全地坚持使用更多静态类型的语言？或者Ruby很好用，这篇文章错过了重点？
答案 0 :(得分：0)
这只是该作者的意见。 他说那是
潜力：是的，滥用应始终是一个问题，任何语言
Spagetti代码可以用任何语言编写，但很少有语言像Ruby那样简洁，优雅和简洁，而且是我所知道的最易读的语言。
我最近阅读了关于Ruby单元测试的this博客文章，并指出＆＃34;测试是重要的...和意见＆＃34;这说明了一切。
This博客也非常有趣，它指出Ruby中的单元测试比Java中的接口要好。
在我看来，Ruby是鼓励和使用单元测试的语言之一。 静态打字是为了给编译器带来快乐，动态打字是为了让开发人员高兴，这是我从某个地方学到的一种说法，书籍是关于这个主题的，每个人都有自己的观点，所以不再关注这个。
Ruby速度慢，首先，代码的编写时间远远低于编译语言，恕我直言的大部分时间比在几秒钟内执行的脚本执行时间和网页更重要以微秒为单位返回。 解释语言的执行速度比编译语言慢：真的，但是一旦需要更高的速度，你可以通过宝石或微服务调用编译的东西。 如果你达到100万用户上限，就可以获得更多的资源，许多大型网络服务开始使用Ruby和Rails，并随着需求的增加转移到其他语言的部分服务。
在我的组织中，我们都使用Ruby和Java，Ruby非常适合自动化脚本，系统管理，临时解决方案，需要更改和配置的脚本，小型Web应用程序以及与Web的交互一般。 开发人员进行自己的测试。使用敏捷和Scrum方法。
Java用于长期开发，更大的组和这些开发人员经常使用很少的测试和oldschool瀑布方法。
Devs通常在第一个好，在第二个坏，反之亦然。
所以这一切都取决于并且非常有意义，我会说继续尝试发表自己的意见。
答案 1 :(得分：0)
我已经意识到我对ruby是否适合大型自动化项目的困惑实际上是更广泛的动态与静态类型辩论的一部分。实际上Ruby可以用JavaScript等替代。
由于Head First专家的视频中提到的原因，我决定坚持使用静态类型语言进行UI自动化测试，因为动态类型语言（如JavaScript和Ruby）具有灵活性，但也灵活性的风险：
https://www.youtube.com/watch?v=lPuQkC6HRPk
Calabash-Ruby组合在测试自动化领域变得流行（可能是因为如果您不熟悉编码，可以轻松学习ruby）。我意识到这个答案可能会被标记下来，因为它认为Calabash-Ruby duo不是大规模自动化测试项目的首选。这只是我的观点，其他人可能不同意。如果你做了downvote，请留下评论为什么我们可以希望进一步教育辩论。如果它是一个明智的选择（而不仅仅是最简单的选择），我绝对愿意接受葫芦红宝石。