使用动态 JVM 语言补充 JUnit 测试电池
我想开始将一系列详细的单元测试（大 json、不可嵌入标准 Java、大量 bean 字段检查）移植到更具表现力的语言（如 Clojure、Groovy、Jython）中。
根据我的经验，能够与标准 Java 源代码相媲美的应该是 Clojure 和 Groovy。可能可以在这里使用 Rhino 或 BeanShell，但我对这些没有经验...
欢迎任何其他建议：
我的要求是：
1）该语言必须在与我的 Java EE 代码相同的环境中运行。
2) 该语言必须能够在字符串中嵌入大型多行文本。
3) 该语言的单元测试必须通过 ANT 和 Maven junit 任务/目标像普通 JUnit 测试一样在本机运行。
4) 该语言的单元测试必须能够本地调用常规代码并使用我的源代码库中的依赖项（即它必须能够访问我的常规 junit 测试包所做的类路径上的类），没有任何问题。
我的问题：
1）是否可以用一种语言编写源代码，同时用另一种junit语言编写junit测试，如果可以，是否有任何例子？
2) 如果是，哪种语言最能满足上述 1-3 条件。
此外，任何关于“用 java 编写，用 * 进行 junit 测试”提案优点的有意义的评论都会有所帮助。
谢谢！
I want to begin porting a series of verbose unit tests (big jsons, not embeddable in standard Java, lots of bean field checking) into a more expressive language (like Clojure, Groovy, Jython).
Languages which should be able to compliment standard Java source code are, from my experience, Clojure and Groovy. Possibly the Rhino or BeanShell could be used here, but I have no experience with these...
Any other suggestions would be welcome :
My requirements are :
1) The language must run, as is, in the same environment as my Java EE code.
2) The language must be able to embed large, multi line text in strings.
3) The language's unit tests must be run natively as normal JUnit tests by the ANT and Maven junit tasks/goals.
4) The language's unit tests must be able to call regular code and work with dependencies in my source code base (i.e. it must have access to the classes on my classpath that my regular junit test package does) natively, with no issues.
My questions :
1) Is it possible to write source code in one language, while also writing junit tests in another junit language, and if so, are there any examples of this?
2) If yes, what language(s) best satisfy 1-3 above.
Also, any meaningful commentary on the merits of this "write in java, junit tests in *" proposal would be helpful.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我曾经在寻找一个满足相同要求的测试库，并且更像
并且 spock是一个强大的框架，可以满足所有的要求。我们可以将 JUNIT 和 Spock 混合在一起。 Spock 生成与 Junit 等格式相同的报告。
示例
I was once looking for a testing library that meets the same requirements and some more like
And spock is a powerful framework that meets all of the requirements. We can mix both JUNIT and Spock together. Spock generates the reports in the same format as Junit etc.
Examples
您使用 IDE 吗？如果是这样，那么抱歉，我是个无聊的老家伙，但我建议您将测试保留在 Java 中。
其原因是，根据我的经验，IDE 对于使用异构代码库没有支持或支持很差。考虑重命名应用程序代码中的方法。对于任何像样的 IDE，您都可以将其视为重构，并且 Java 代码中的所有调用站点都会更改以反映新名称。但是，其他语言的调用站点不会（据我所知）。如果您的测试不是使用 Java 进行的，则意味着您现在有一堆损坏的测试需要查找和修复。只是因为你重命名了一个方法！许多重构都会引发这个问题。您还可能会遇到无法在测试和应用程序代码上同时使用调试器、运行代码覆盖率分析或执行各种其他有用操作的问题。
使用非类型化语言（例如通常使用的 Javascript 或 Groovy）本质上也意味着您的测试无法对类型进行断言，因此无法测试 Java 中可能出错的全部内容。例如，在 Java 测试中，我可以编写：
为了使该测试能够编译，
getWords必须返回一个List。如果有人将其更改为List，测试就会失败。这使您可以使用测试来强制执行 API 的设计。那么，另一种方法可能是使用 Java，并找到处理大字符串和大 bean 比较的方法。
处理大字符串的最简单方法可能是将它们推送到单独的文本文件中，这些文本文件是类路径资源。然后，您可以编写一个简单的实用程序方法来加载命名资源，并将其读入字符串。
我不知道你的“大量 bean 字段检查”涉及什么，但如果它检查 bean 字段中的值（可能是深度嵌套的），那么一些简单的实用方法可能会有很大帮助。也许您可以从属性文件中读取字段的规范及其预期值，并反思性地提取和检查它们？
Are you using an IDE? If so, then sorry to be a boring old fart, but i would suggest keeping your tests in Java.
The reason for this is that IDEs, in my experience, have no or poor support for working with heterogeneous codebases. Think about renaming a method in your application code. With any decent IDE, you do this as a refactoring, and all call sites in Java code get changed to reflect the new name. However, call sites in other languages will not (as far as i know). If your tests are in something other than Java, that means you now have a pile of broken tests to find and fix. Just because you renamed a method! Many kinds of refactorings will raise this problem. You may also suffer from an inability to use a debugger on your test and application code together, to run code coverage analysis, or to do various other useful things.
Using an untyped language, like Javascript, or Groovy as it is usually used, also inherently means that your tests can't make assertions about types, and so can't test the full range of things that can go wrong in Java. For example, in a Java test, i can write:
And for that test to even compile,
getWordshas to return aList<CharSequence>. If someone changes it to aList<String>, the test breaks. That lets you use the test to enforce the design of an API.Another approach, then, might be to use Java, and to find ways to deal with large strings, and large bean comparisons.
The easiest way to deal with large strings is probably to push them out into individual text files which are classpath resources. You can then write a simple utility method to load a named resource, and read it into a string.
I don't know exactly what your "lots of bean field checking" involves, but if it's checking the values in fields of beans, perhaps deeply nested, then some simple utility methods could help a lot. Perhaps you could read specifications of fields and their expected values from properties files, and reflectively extract and check them?
我用 easyb（一种基于 Groovy 的 BDD 语言）编写了很多测试。 JRuby 和 RSpec 是另一个不错的选择。为什么要求测试“作为 JUnit 测试”运行，这到底意味着什么？
如果这是一个实际要求，那么您会限制测试的表达能力（我不是 JBehave 的忠实粉丝）。尽管我使用 JRuby 作为应用程序的命令行界面，但 Groovy 是我在进行 Java + 真实语言项目时选择的语言。
Groovy 的注释支持是一流且无缝的，在我看来，这是一个轻松采用的编写 JUnit 测试的选择，或多或少就像您在 Java 中编写它们一样，但在 Groovy 中。
I write a lot of tests in easyb, a Groovy-based BDD language. JRuby and RSpec is another great option. Why is there a requirement that the tests be run "as JUnit tests", and what exactly does it mean?
If that's an actual requirement, you limit in the expressiveness of your tests (I'm not a big fan of JBehave). Groovy is my language of choice when doing a Java + real language project, although I use JRuby for command-line interfaces to the app.
Groovy's annotation support is top-notch and seamless, IMO it's a no-brainer choice for ease of adoption for writing JUnit tests, more or less as you'd write them in Java, but in Groovy.