jUnit 测试 addAll 方法
对于我的作业,我必须为该方法开发几个 jUnit 测试:
addAll(int index, Collection c)
该方法是内置于 java 中的 ArrayList 类的一部分。
我弄清楚了如何创建测试并在 Eclipse IDE 中运行它们,但我对到底应该如何开发测试感到有点困惑。我能否得到一个示例,其中包括我应该在 @before
、@beforeClass
、@after
、@test
中包含的内容代码>方法?
为了弄清楚这一点,我理解这些方法的格式......我只是不明白如何测试这个方法。
For my assignment, I have to develop several jUnit tests for the method:
addAll(int index, Collection c)
This method is part of the class ArrayList
- built in to java.
I figured out how to create the tests and run them in Eclipse IDE, but I'm a little confused as to exactly how I'm supposed to develop the tests. Could I get an example that includes what I should have in a @before
, @beforeClass
, @after
, @test
method?
To make this clear, I understand the format of the methods...I just don't understand HOW to test this method.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
因此,您需要测试的是该方法是否插入了传递的 Collection 中的所有元素,并将它们插入到 ArrayList 中的适当位置。
考虑所有可能的情况并测试每一种。
添加后,验证/断言 ArrayList 现在具有正确顺序/位置的所有元素。
还可以使用 @Test(expected=...) 测试错误情况。
另外... assertThat 与 Hamcrest 的 IsIterableContainingInOrder 结合将有助于验证。
So, what you need to test is that the method inserts all the elements in the passed Collection and that it inserts them into the appropriate position in the ArrayList.
Think of all the possible senerios and test each one.
After the add, verify / assert that the ArrayList now has all the elements that it should have in the correct order / locations.
Also test the error cases with @Test(expected=...).
Also... assertThat in combination with Hamcrest's IsIterableContainingInOrder would be helpful for verification.
您需要考虑要测试的行为,然后创建许多用 @Test 注释的方法来测试该行为的各个方面。考虑一下 addAll 应该如何表现。例如,如果传递给它的集合且索引为 0,那么它应该将所有这些元素添加到 ArrayList 的索引 0 中,然后添加先前存在的对象。因此,在您的测试方法中,创建一个 ArrayList,在其中粘贴一些对象,创建一个集合 (c),在其中粘贴一些对象,使用索引 0 和集合 (c) 在 arrayList 上调用 addAll,并断言它已完成它应该做什么...
(这只是一个例子,我不确定在你的情况下 addAll 的确切预期行为是什么)
更好地看看 Vakimshaar 发布的维基百科文章:)
You will need to think of the behaviour you want to test, and then create a number of methods annotated with @Test to test aspects of that behaviour. Think about how should addAll behave. For example, if a collection passed to it, and an index of 0, then it should add all those elements in index 0 of ArrayList, followed by previously existing objects. So, in your test method, create an ArrayList, stick some objects in it, create a collection (c), stick some objects in it, call addAll on your arrayList with index 0 and collection (c), and assert that it has done what it was supposed to do...
(That's just an example, I am not sure what is the exact expected behaviour of addAll in your case)
Even better take a look at the wikipedia article Vakimshaar posted :)
坚持使用 @Test 和 @Before 方法,其余的可能不是您所需要的。
每次使用 @Test 注解的方法执行之前,都会调用使用 @Before 注解的方法。您可以使用它来将内容初始化为干净状态,该状态可以在多个测试之间共享。
起点可以是以下代码(要测试更多案例,请查看约翰的答案)并自己实现它们。
Stick with @Test and @Before Methods, the rest is probably not what you need.
Methods annotated with @Before get called every time before a method annotated with @Test is executed. You can use it to initialized stuff to a clean state which might be shared among multiple tests.
A starting point could be the following code (for more cases to test take a look at John's answer) and implement them yourself.
使用注释
@Test
来标记应该返回void并且不应该接受参数的测试方法。对于大多数用途来说这已经足够了。但是,如果您想在每次测试之前或之后运行特定代码,请使用实现适当的方法并使用 @Before 和 @After 注释来标记它们。
如果您需要一些在测试用例(实现多个测试的类)之前或之后运行的代码,请使用 @BeforeClass 和 @AfterClass 方法注释适当的方法。请注意,这些方法必须是静态的,因此“before”方法是在测试用例的默认构造函数之前执行的事件。如果您愿意,也可以利用这一事实。
Use annotation
@Test
to mark test method that should return void and should not accept arguments.For most usages this is enough. But if you want to run specific code before or after each test use implement appropriate method and mark them with @Before and @After annotation.
If you need some code that runs before or after test case (the class where you implement several tests) annotate appropriate methods using @BeforeClass and @AfterClass method. Pay attention that these methods must be static, so "before" method is executed event before the default constructor of your test case. You can use this fact if you wish too.