代码之家 › 专栏 › 技术社区 › Hannoun Yassir

我应该强制例外来测试它们吗?

logging exception unit-testing .net c#

Hannoun Yassir · 技术社区 · 15 年前

我的数据访问类中有这个方法,并且我有一个单元测试来确保它正常工作,但是我的测试没有测试异常,所以我的问题是我应该创建一个新的测试来强制引发异常,还是应该只相信catch块在例外?值得努力吗?

下面是一个例子:

public void UpdateProject(Project project)
    {
        using (var transaction = _session.BeginTransaction())
        {
            try
            {
                _session.Update(project);
                _session.Flush();
                transaction.Commit();
            }
            catch (HibernateException)
            {
                transaction.Rollback();
                throw;
            }
        }
    }

8 回复 | 直到 6 年前

Reed Copsey 15 年前

理想情况下,您应该尝试测试每一行代码,您可以…这意味着强制发生异常来测试异常处理程序,并确保其正常工作。

在实践中,总会有一些代码行没有被覆盖——但是,我会通过模拟来强制异常,以便测试任何您认为是关键的异常处理程序,特别是在生产中可能发生的异常处理程序。

P Shved 15 年前

在linux内核中,驱动程序中80%的错误都在错误处理代码中。

异常处理是许多错误的根源,您肯定应该测试所有异常路径。

当然,你不能测试每一行代码。但据统计,程序员对异常处理的关注较少,因此必须对它们进行彻底的测试。

Christian 15 年前

以下是我的故障行为理想测试规则:

如果你正在使用 依赖关系 这可能会抛出异常,那么您应该包括单元测试,使您的模拟抛出异常。
如果在某些条件下 你的代码 应该抛出异常,然后应该包含设置此类条件的单元测试。

第一让您知道代码在外部失败时的行为,并经常导致重新考虑该做什么。在任何情况下,看到实际发生的事情都是很好的。第二只要确保您遵守您的承诺,只要您的代码应该检测到错误并认为异常。这与测试代码中的其他特性没有区别。

在考虑完成单元测试套件之前,应该先看一下 代码覆盖率 正在测试的代码。对于不重要的代码,几乎总是有一种方法,我的代码分支,我的单元测试不覆盖,或者更糟,有我不打算的行为。令人惊讶的是,解决方案往往是删除代码,而不是添加更多的测试。只是在早些时候挥舞时留下的拐杖。

我并不一定要说一个人应该达到100%的覆盖率,但是一个人应该进行代码覆盖率驱动的单元测试,因为这是一种更直观的方式来理解和公开存在的代码行为。看看它可以给你如何重构代码的新思路。 Single Responsibility Principle 和 Separation of Concerns 。

dove 15 年前

您可以让会话模拟抛出异常,但不需要测试catch是否有效。

如果更新抛出异常,那么编写一个测试来检查事务是否回滚并没有错,但从本质上讲,我认为这太过分了。

也许一个更为复杂的案子会证明这一点。

另外,您是否不会回滚任何类型的异常?

Ian Ringrose 15 年前

我希望如果在commit()之前调用displase(),事务将回滚,因此您需要捕获吗?

至于其他情况,如果你的渔获物做得更多,那么只需记录问题,我认为应该进行单元测试。 但是不要让你不能做利润的单元测试阻止你做一些单元测试。

grigy 15 年前

从异常名称(hibernateexception)来看,我认为这不是一个异常情况。所以在正常操作时可能发生。如果是这样的话,我会做一个测试,使异常得到正确处理。

MikeJ 15 年前

我肯定会测试捕获和处理的每个特定异常。至少在处理代码中有一些执行路径,这会给您一些安慰,当/如果您在运行时遇到这样的异常,就不会发生其他奇怪的事情。

记住,你只需要测试你想工作的代码。

ilya n. 15 年前

我当然希望你能单独测试 transaction.Rollback() 通过测试可以排除所有可能的情况。但是,如果测试是详尽无遗的,我可能不会去处理异常,因为处理程序中没有其他东西。