Question

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

不要测试任何不涉及逻辑的内容。例如：如果服务层中有一个方法只调用数据访问层中的另一个方法，则不要对其进行测试。
不测试基本数据库操作。如果我在DAL中有一个简单的方法在数据库中插入一个对象，说“public void save（Object object）{...}”并且没有对从服务层接收的对象进行处理，请不要测试它。
我不需要验证所有图层的对象。这意味着对象中的某个字段应该不为null，比如用户对象中的emailId，这是在JSP（使用JS）上验证和验证的，我不需要测试DAL方法在接收emailId时的行为方式= NULL，因为理想情况下它不应该，这应该由JS来处理。

我还应该测试什么？

Answer 1

我不确定我是否同意您在答案中提及的任何例外情况。

不涉及逻辑的方法

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

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

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

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

请记住：简单的事情并不能保证简单。

未测试数据库操作

您是否发现数据是否在数据库中正确保留是无关紧要的？如果你真的，真的，不在乎，那么你不需要测试它 - 否则就是你。

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

我不是说您应该测试您的ORM库，但是您应该测试它是否正确使用。

不测试所有图层中的对象

我不确定你对这个问题的意思，但是如果一个字段可以为空，这是一个问题，你需要测试当它实际上是无效的时候发生的事情 - 无处不在。

然后，更可取的是设计您的API，以确保值不为空。

<强>结论

您应该测试可以测试的所有内容。没有例外。简单的事情并不简单，您需要能够验证曾经工作过的代码是否能继续工作。

有些东西（例如UI）你无法进行单元测试，这些东西应该被抽象掉，以便它们包含尽可能少的逻辑，但其他一切都应该进行测试。< / p>

测试驱动开发（TDD）是确保发生这种情况的最佳方法。

Answer 2

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

但更重要的是你的观点。

这一切都取决于你的逻辑意思。我在映射层上采用了这种方法。我没有测试将属性值从对象A复制到对象B的所有无聊代码。错误的复制粘贴和我复制了一个副本而错过了另一个。大事件。但它是否值得所有额外的测试代码？取决于应用程序失败时会发生什么。在这种情况下，测试代码是值得的。
与第一点类似。所以Save非常简单，但是你怎么知道你做的很简单。弄乱那些就像弄错业务逻辑一样糟糕。
您不想重新测试已测试过的内容。但你应该超越单元测试。进行集成和回归测试以及单元测试。当所有部件在真空中工作但在放在一起时会爆炸，这真的很不错。

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

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

Answer 3

简单回答 - 没有

复杂的答案 - 你不应该测试你没有时间的东西。测试由需要且经济实惠的测试的复杂计划驱动，优先考虑软件系统的最重要部分和工作流程。剩下更多的时间用于测试，可以测试更多的侧箱。

在UnitTesting中，每个单元都在OOP中，每个类都有自己的测试。使用值min，max，average usecases测试所有内容，并进行否定测试 - 如果软件正常工作则必须失败的测试。测试错误处理。

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

Answer 4

一般来说，如果可能，我会选择TDD风格。这很难实现，需要很多纪律，但如果你拥有它，你永远不会想要回归。顺便说一下，TDD不只是测试，而是更多关于软件设计（也可以称为测试驱动设计）。您的设计会根据您的测试而发展。

马克确实对你不测试的陈述给出了很好的答案。

我不需要验证对象所有图层。这意味着某个领域例如，在一个对象中应该不为null 用户对象中的emailId，以及此已经过验证和验证 JSP（使用JS），我不需要测试 DAL方法如果表现如何接收emailId = NULL，因为理想情况下它不应该，这应该是由JS照顾。

在分层应用程序中，您的应用程序可能会有两种“前端”/入口点。一个可以是普通的web用户界面，另一个可以是由一些其他应用程序（可能是桌面应用程序）消费的web服务。因此，应该（也）在业务层中检查与验证相关的所有逻辑（因为验证可能是业务逻辑的一部分）。

Answer 5

不要对.NET框架进行单元测试。我的意思是，不要测试微软负责的事情。

例如，不要费心去测试setter和getter - 除非那里有实际的代码。

Answer 6

等等，JS是指JavaScript吗？我假设你指的是客户端验证呢？在构建网站时，您永远不应假设客户验证任何内容。可以禁用JavaScript，可以更改或伪造页面等。

Answer 7

我不同意你的观点。您不应该根据代码的编写方式编写单元测试，但为了确保将来，如果其他开发人员更改了代码的随机部分，他可以运行它们并确信一切都很好。

例如，您可能想要测试只调用另一个的方法。毕竟，你只对外部方法有效，而不是它如何工作感兴趣。如果下一个开发人员改变了外部方法，那就不再那么简单了，他将缺少单元测试。

这就是为什么你应该使用像NCover这样的工具来确保在单元测试中执行100％代码的原因！

Answer 8

如果你有已经有效的东西，可能不值得花时间在它周围写一堆测试。需要注意的是，如果您需要对其进行更改或使用它的代码，那么这些测试是非常宝贵的。

至于不需要测试DAL对无效输入的处理......你需要弄清楚你的服务边界是什么。这真的取决于。如果您无法控制客户端，那么您需要测试服务器的期望是否得到满足（在某个层）。

Answer 9

我不是单位 - 测试任何东西，因为我希望集成和/或系统测试：

覆盖代码
自动化
用作单元测试并且与单元测试一样有用

有关详细信息，请参阅Should one test internal implementation, or only test public behaviour?

撤消您的问题，我建议您应单元测试的唯一代码是代码：

a）通过集成和/或系统测试不会对进行测试（如果没有，为什么不呢？）

b）或者，无论出于什么原因，应该在集成/系统测试之前测试（可能是因为你的项目的开发如何并行地划分给几个开发人员）

单元测试 - 什么不测试

9 个答案: