JUnit 测试 - 我要测试什么？
如果我有一个返回 ArrayList 的基本访问器方法，
我到底要测试什么？ 我在测试方面非常缺乏经验。
If I have a basic accessor method that returns an ArrayList
What exactly would i test for it?
I am very inexperienced when it comes to testing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这取决于您期望该方法的行为方式。例如：如果有人调用了该方法并更改了检索到的列表，您是否希望这些更改在下次调用 getter 时显示？无论哪种方式，测试该行为。当列表为空时，getter 返回什么？空列表还是空列表？这也应该进行测试。
That depends on how you expect the method to behave. For example: If someone has called the method and changed the list that was retrieved, do you want those changes to show up the next time the getter is called? Either way, test that behaviour. What does the getter return when the list would be empty? Null or an empty list? This should also be tested.
通常，为访问器编写显式 Junit 测试通常有点矫枉过正（您在测试什么？ return foo;）。使用代码覆盖率工具，例如clover 可以帮助您首先针对最复杂的代码进行测试。
Typically writing explicit Junit tests for accessors is usually a little overkill (what are you testing? return foo;). Using a code coverage tool such as clover can help you target your testing efforts at your most complicated code first.
您感兴趣的问题：
单元测试应该“测试”多少
如何有效地使用 Junit 和 Hibernate
什么不应该进行单元测试
编辑：
在 Stackoverflow 上添加了一些我最喜欢的有关 JUnit 和单元测试的问题。
Interessting question for you:
How much should a unit test "test"
How to use Junit and Hibernate usefully
What should not be unit tested
Edit:
Added some of my favorite Questions here on Stackoverflow regarding JUnit and Unit Testing.
始终记住，测试代码也是代码，每 1,000 行代码，您至少会产生 4 个错误。因此，测试不起作用的东西，不要为不可能破坏的东西（比如 IDE 生成的代码）编写测试。如果它确实损坏，请编写一个测试:)
Always keeps in mind that test code is also code and for every 1,000 lines of code, you produce at least 4 bugs. So test what doesn't work and don't write tests for something that can't possibly break (like code generated by your IDE). If it does break, write a test :)
一般来说，单元测试应该测试您的方法是否执行其规定的操作。
如果您的方法返回一个数组列表，您的基本测试是断言调用时确实返回了一个数组列表。
测试的下一个细节是检查数组列表是否正确构造？您期望的值是否已正确填写？如果它应该是一个空列表，是这样吗？
现在您有了“晴天”情况（即该方法在正常条件下有效），您应该在适当的情况下添加一些负面（或“雨天”）条件。如果该方法接受数组的长度，如果传入负数或 int.Max 等会怎样。
如另一个答案中所述，这对于简单的访问器来说可能有点过大，但这些原则适用于您需要的任何单元测试写。
In general unit tests should test that your method does what it states it should do.
If your method returns an arraylist your basic test is to assert that an arraylist is indeed returned when it is called.
The next level of detail in the test is to check is the arraylist constructed correctly? Have the values you expect in it been filled correctly? If it's supposed to be an empty list, is that the case?
Now you have your "sunny day" case (i.e the method works under normal conditions) you should add some negative (or "rainy day") conditions if appropriate. If the method accepts a length for the array, what if you pass in a negative number or a int.Max etc.
As stated in another answer, this is probably overkill for a simple accessor, but the principles apply to any unit tests you need to write.
取决于您的要求。您可以测试：
但是，正如我所说，这取决于要求，取决于您调用访问器时期望的集合的“类型”。也许您允许将列表设置为
null但创建一个空列表。当您将列表设置为空时，测试可以确保您确实得到一个空列表。希望能给你带来帮助，给你一个想法！
Depends on your requirements. You might test:
But, as I said, it depends on the requirements, it depends on the 'kind' of collection you expect when you call the accessor. Maybe you allow setting the list to
nullbut create an empty list. The the test could make sure that you really get an empty list when you set the list to null.Hope it helps to give you an idea!