单元测试 - 什么不应该测试 [英] Unit Testing - What not to test
问题描述
我浏览了许多关于 stackoverflow 的帖子和许多关于单元测试的文章.我只是想弄清楚我的理解是对的.
I have gone through a number posts on stackoverflow and numerous articles about Unit Tests. I am just trying to figure out that what I have understood is right.
不要测试任何不涉及逻辑的东西.例如:如果服务层有一个方法只是简单地调用了数据访问层的另一个方法，就不要测试.
Do not test anything that does not involve logic. For example: If there is a method in the service layer which simply invokes another method in the data access layer, don't test it.
不要测试基本的数据库操作.如果我在 DAL 中有一个方法可以简单地在数据库中插入一个对象，请说public void save(Object object){...}"并且没有对从服务层接收到的对象进行处理，不要测试一下.
Do not test basic database operations. If I have a method in the DAL which simple inserts an object in the database, say "public void save(Object object){...}" and there is no processing done on the object received from the service layer, don't test it.
我不需要验证所有层的对象.这意味着对象中的某个字段不应该为空，比如用户对象中的 emailId，这是在 JSP(使用 JS)中验证和验证的，我不需要测试 DAL 方法在收到 emailId 时的行为方式=NULL，因为理想情况下不应该，这应该由 JS 处理.
I don't need to validate objects at all layers. This means a certain field in an object should be not null, say the emailId in User Object, and this is verified and validated at the JSP(Using JS), I don't need to test how the DAL method behaves if it receives emailId=NULL, because ideally it should not, and this should be taken care by the JS.
还有什么我不应该测试的?
What else should I be not testing?
推荐答案
我不确定我是否同意您在回答中提到的任何例外情况.
I'm not sure I can agree with any of the exceptions that you mention in your answer.
不涉及逻辑的方法
即使一个方法只是简单地将其实现委托给一个内部依赖项，验证它是否发生也是非常相关的.我认为您编写代码是有原因的，因此您需要编写一个测试以确保它保持这种状态.
Even if a method simply just delegates its implementation to an inner dependency, it is very relevant to verify that it happens. I presume that you write code for a reason, so you need to write a test that ensures that it stays that way.
请记住，单元测试的主要优势之一是作为回归测试套件.测试内部依赖是否被正确调用称为交互测试.假设您有以下方法:
Remember that one of the key benefits of unit tests are as regression test suites. Testing that an inner dependency is being correctly invoked is called Interaction Testing. Say that you have the following method:
public void Save(Entity entity)
{
this.repository.Save(entity);
}
测试是否使用正确的输入调用了存储库的 Save 方法非常重要.否则，其他一些开发人员可能会在稍后出现并删除该行代码，并且回归测试套件不会提醒您.
It is very important to test that the repository's Save method is being invoked with the correct input. Otherwise, some other developer could come along at a later date and delete that line of code and the regression test suite wouldn't alert you.
记住:简单的事情不能保证保持简单.
Remember: Simple things are not guaranteed to stay simple.
未测试数据库操作
您是否认为数据是否正确持久保存在数据库中无关紧要?如果你真的真的不关心，那么你就不需要测试它 - 否则你会这样做.
Do you find it inconsequential whether data is being persisted correctly in the database? If you really, truly, don't care, then you don't need to test it - otherwise you do.
如果你不测试你的数据库操作，你怎么知道你的数据访问组件工作正常?
If you don't test your database operations, how do you know that your data access component works?
我并不是说你应该测试你的 ORM 库，但你应该测试它是否被正确使用.
I am not saying that you should test your ORM library, but you should test that it is being used correctly.
未在所有层中测试对象
我不知道你说的这个问题是什么意思，但如果一个字段可以为空，这是一个问题，你需要测试当它实际上为空时会发生什么 - 无处不在.
I'm not sure what you mean by this question, but if a field can be null, and this is a problem, you need to test what happens when it is, in fact, null - everywhere.
那么，最好设计 API 以保证值不为空.
It is much more preferable, then, to design your API so that values are guaranteed not to be null.
结论
您应该测试您可以测试的所有内容.没有例外.简单的事情并不总是简单的，您需要能够验证曾经工作过的代码是否继续工作.
You should test everything you can test. No exceptions. Simple things don't stay simple, and you need to be able to verify that code that once worked keeps working.
有些内容(例如 UI)您不能单元测试，这些内容应该被抽象掉，以便它们包含尽可能少的逻辑，但其他所有内容都应该进行测试.
There are things (such as UI) that you can't unit test, and these should be abstracted away so that they contain as little logic as possible, but everything else should be tested.
测试驱动开发 (TDD) 是确保这种情况发生的最佳方式.
Test-Driven Development (TDD) is the best way to ensure that this happens.
这篇关于单元测试 - 什么不应该测试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
