单元测试 - 什么不测试

Question

我已经浏览了stackoverflow上的一些帖子和关于单元测试的大量文章.我只想弄清楚我所理解的是对的.

1. 不要测试任何不涉及逻辑的东西.例如:如果服务层中有一个方法只是调用数据访问层中的另一个方法,请不要测试它.

2. 不要测试基本的数据库操作.如果我在DAL中有一个简单的方法在数据库中插入一个对象,说"public void save(Object object){...}"并且没有对从服务层接收的对象进行处理,请不要测试一下.

3. 我不需要在所有层验证对象.这意味着对象中的某个字段应该不为null,比如用户对象中的emailId,并且这在JSP(使用JS)中验证和验证,我不需要测试DAL方法在接收emailId时的行为方式= NULL,因为理想情况下它不应该,这应该由JS来处理.

我还应该测试什么？

Answer 1

我不确定我是否同意你在答案中提到的任何例外情况.

不涉及逻辑的方法

即使方法只是将其实现委托给内部依赖项,验证它是否发生也是非常相关的.我认为你出于某种原因编写代码,所以你需要编写一个测试来确保它保持这种状态.

请记住,单元测试的主要好处之一是回归测试套件.测试正确调用内部依赖项称为交互测试.假设您有以下方法:

public void Save(Entity entity)
{
    this.repository.Save(entity);
}

测试使用正确的输入调用存储库的Save方法非常重要.否则,其他一些开发人员可能会在以后出现并删除该行代码而回归测试套件不会提醒您.

请记住:简单的事情并不能保证简单.

不测试数据库操作

您是否发现数据是否在数据库中正确保留是无关紧要的？如果你真的,真的,不在乎,那么你不需要测试它 - 否则你会这样做.

如果您不测试数据库操作,您如何知道您的数据访问组件是否有效？

我不是说你应该测试你的ORM库,但你应该测试它是否正确使用.

不测试所有图层中的对象

我不确定你对这个问题的意思,但是如果一个字段可以为空,这是一个问题,你需要测试当它实际上是无效的时候到处都会发生什么.

因此,更可取的是设计API以确保值不为空.

结论

你应该测试你可以测试的一切.没有例外.简单的事情并不简单,您需要能够验证曾经工作的代码是否能够正常工作.

有些东西(比如UI)你无法进行单元测试,这些东西应该被抽象掉,以便它们包含尽可能少的逻辑,但其他一切都应该进行测试.

测试驱动开发(TDD)是确保发生这种情况的最佳方法.

Answer 2

不要测试任何不能失败的东西.

但更重要的是你的观点.

1. 这一切都取决于你的逻辑意味着什么.我在映射层上采用了这种方法.我没有测试将属性值从对象A复制到对象B的所有无聊代码.错误的复制粘贴和我复制了一个副本而错过了另一个.大事件.但它是否值得所有额外的测试代码？取决于应用程序失败时会发生什么.在这种情况下,测试代码是值得的.

2. 与第一点类似.所以Save非常简单,但是你怎么知道你做的很简单.弄乱那些就像弄错业务逻辑一样糟糕.

3. 您不想重新测试已测试的内容.但你应该超越单元测试.进行集成和回归测试以及单元测试.当所有部件在真空中工作但在放在一起时会爆炸,这真的很好.

测试是一种平衡行为.如果你真的测试它,你可能永远不会做任何其他事情.但是,如果你没有对它进行足够的测试,那么你就会花费所有时间来修复bug 那个平衡点是变化的地方.不同类型的项目有不同的失败成本.在某些项目中,例如了解内部用户的项目,您可能能够快速,快速地运行,但需要多长时间？最终未经测试的代码中断,需要一段时间才能找到并且您没有取得任何进展.

最好的办法是遵循真正的TDD.不要为测试而测试.作为设计技术测试.测试,因为它驱逐松散耦合的代码.测试因为在两个上下文(测试和应用程序)中执行代码会产生更好的代码.一旦你走上TDD的道路,你不会问你应该和不应该测试什么.测试只是编写代码而不是独立活动的一部分.

Answer 3

简单的答案 - 没有

复杂的答案 - 你不应该测试你没有时间做的事情。测试是由所需和负担得起的测试的复杂计划驱动的，优先考虑软件系统的最重要部分和工作流程。留给测试的时间越多，可以测试的边际案例就越多。

在 UnitTesting 中，每个单元，在 OOP 中，每个类都有自己的测试。用最小值、最大值、平均用例的值简单地测试一切，并进行负面测试——如果软件工作正常，测试必须失败。还要测试错误处理。

有关该主题的更多详细信息，请参阅ITSQB