在以下示例中,
1. <target name="tests.unit">
2. <junit>
3. <batchtest>
4. <fileset dir="tsrc">
5. <include name="**/Test*.java"/>
6. <exclude name="**/tests/*.java"/>
7. </fileset>
8. </batchtest>
9. </junit>
10. </target>
11. <target name="tests.integration">
12. <junit>
13. <batchtest>
14. <fileset dir="tsrc">
15. <include name="**/tests/Test*.java"/>
16. </fileset>
17. </batchtest>
18. </junit>
19. </target>
如果我在** / tests /文件夹中有多个TestSuite。如果我运行tests.integration目标,它将如何知道首先运行哪个测试套件?如果我有TestSuite1.java,TestSuite2.java和TestSuite3.java,我希望测试套件按照teh filename中指定的顺序运行。
答案 0 :(得分:1)
除非JUnit中有新功能,否则这很难做到。
TestNG可以使用依赖组来管理它。
这是一个问题:为什么订单很重要?单元测试不应具有依赖性。如果你这样做,也许这些都是集成测试。
FitNesse可能是一个更好的方式。
答案 1 :(得分:1)
您可以创建一个基础测试类,将登录信息放在setUp()
中,并从这一个继承所有测试用例(当然,到处调用super.setUp()
)。
请注意,这只是一个简单的登录,而不是一个适当的单元测试。您应该使用所有可能的疯狂用户输入以及在单独的测试类中进行单元测试您的登录功能,但对于其他测试用例,您只需要使用默认用户名或其他内容进行简单的简单登录。
对于那些在登录之上您还需要产品的测试用例,您可以创建第二个基础测试类,该类扩展第一个并将产品创建添加到其setUp()
。
无代码重复 - 如果登录更改,除了登录测试用例本身之外,您还需要更改测试代码中的单个方法。
以这种方式执行5000单元测试可能会更慢 - 但更安全。如果你开始依赖于单元测试的执行顺序,你就会踩到滑坡。如果您的配置修复了它们的顺序,则很难注意到您无意中在两个单元测试之间引入了额外的依赖关系。例如。您在一个单元测试中设置产品的特定属性或更改全局配置设置,然后在下一个测试用例中测试产品上的其他内容 - 并且它恰好只是因为之前的单元测试设置了特定的办法。这迟早会导致令人讨厌的惊喜。
答案 2 :(得分:0)
是的,我正在尝试为功能测试而不是单元测试创建测试套件。我试图使用junit来构建功能测试包。我使用的是基于Junit的硒。
假设我有一个网站,你无法登录而无法做任何事情。在这种情况下,我有一个测试案例,测试登录功能,然后我将有另一个测试案例,将测试其他东西。它们将被执行的顺序很重要,因为在登录之前我无法测试任何东西,这意味着订单应该是
在上面的测试用例中,在创建之前我无法读取任何产品并且我已经登录并且在我登录之前无法创建产品。我已经看到很多关于使用setUp()和tearDown()方法的评论,但肯定会有很多重复。
例如,如果我必须使TestReadProduct测试用例独立,我必须将TestLogin和TestCreateproduct功能放在TestCreateProduct测试用例的setUp()方法中。当然这是一场维护噩梦。想象一下,必须维护5000个测试用例。如果TestLogin功能发生变化,我将不得不在很多地方做出很多改变。
我正在考虑在ANT中使用“depends”选项。
像这样的东西
<target=TestReadProduct depends=TestLogin, TestCreateProduct>
不是有更好的方法吗?