新的 JUnit 4.8.1 @Category 渲染测试套件几乎已经过时了吗？
给定问题 “如何运行属于某个类别的所有测试？”以及答案以下方法对测试组织来说会更好吗？
- 定义包含所有测试的主测试套件（例如使用ClasspathSuite）
- 设计足够的JUnit集类别（充分意味着每个所需的测试集合都可以通过一个或多个类别来识别）
- 使用相关类别来限定每个测试
- 根据主测试套件和类别集定义目标测试套件
示例：
- 识别速度类别（慢、快） ）、依赖项（模拟、数据库、 集成等）、功能（填写适用类别）、领域（填写适用类别）等。
- 要求每个测试都通过相关的适当资格（标记）类别集。
- 使用 ClasspathSuite 创建主测试套件（在类路径中找到的所有测试）
- 通过使用类别限定主测试套件来创建目标套件，例如 模拟测试套件、快速数据库测试套件、域 X 测试套件的缓慢集成等。
我的问题更像是征求这种方法与经典测试套件方法的批准率。一个无与伦比的好处是每个新测试都会立即包含在相关套件中，无需套件维护。一个问题是每个测试的正确分类。
Given question 'How to run all tests belonging to a certain Category?' and the answer would the following approach be better for test organization?
- define master test suite that contains all tests (e.g. using ClasspathSuite)
- design sufficient set of JUnit categories (sufficient means that every desirable collection of tests is identifiable by one or more categories)
- qualify each test with relevant category(ies)
- define targeted test suites based on master test suite and set of categories
Example:
- identify categories for speed (slow, fast), dependencies (mock, database,
integration, etc.), function (fill in applicable categories), domain (fill in applicable categories), etc. - demand that each test is properly qualified (tagged) with relevant set of categories.
- create master test suite using ClasspathSuite (all tests found in classpath)
- create targeted suites by qualifying master test suite with categories, e.g.
mock test suite, fast database test suite, slow integration for domain X test suite, etc.
My question is more like soliciting approval rate for such approach vs. classic test suite approach. One unbeatable benefit is that every new test is immediately contained by relevant suites with no suite maintenance. One concern is proper categorization of each test.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您必须考虑的权衡之一是恕我直言，类别是在测试内定义的，而套件是在外部定义的。这意味着，当您使用套件时，您知道将运行哪些测试，但是当使用类别时，您不知道，除非您检查测试或简单地运行它们。同时，当您使用测试套件查看测试时，您不知道它包含在哪个套件中，除非检查您的套件，但使用类别，您会立即看到它。
One of the trade-off you have to consider is IMHO that categories are defined within the tests and suites are defined outside. This means, that when you use suites, you know which tests will be run, but when using categories, you do not know unless you inspect tests or simple run them. At the same time, when you look at the test using test suites you do not know in which suite it is contained, unless checking your suites, but using categories, you see it immidiatly.