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

Question

我在我的数据访问类中有这个方法，我有一个单元测试，以确保它正常工作，但我的测试不测试异常所以我的问题是我应该创建一个新的测试来强制引发异常或我应该相信catch块在异常的情况下会正常工作吗？ 值得努力吗？

这是一个例子：

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

Answer 1

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

在实践中，总会有一些代码行未被覆盖 - 但是，我会通过模拟强制执行异常，以便测试任何您认为至关重要的异常处理程序，尤其是在生产中可能发生的异常处理程序。

Answer 2

在Linux内核中，驱动程序中80％的错误都在错误处理代码中。

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

当然你无法测试每一行代码。 但统计数据显示程序员对异常处理的关注较少，因此您必须彻底测试它们。

Answer 3

以下是我对失败行为进行理想测试的规则：

• 如果您正在使用可能会抛出异常的依赖项 ，那么您应该包含单元测试，这些单元测试会使您的模拟程序抛出异常。
• 如果在某些条件下你的代码应该抛出异常，那么你应该包括设置这些条件的单元测试。

第一个让你知道你的代码在外部失败时的行为，并经常导致重新考虑做什么。 在所有情况下，很高兴看到实际发生的事情。 第二个只是确保你保留你所承诺的内容，只要你的代码应该检测到的错误并考虑异常。 它与测试代码中的其他功能没什么不同。

在考虑完成单元测试套件之前，应该先看看被测代码的代码覆盖率 。 对于非平凡的代码，我的代码分支几乎总是有一种方法，我的单元测试没有覆盖，或者更糟糕的是，我有不想要的行为。 令人惊讶的是，解决方案是删除该代码而不是添加更多测试。 只是在早些时候甩开它时留下了残余物。

我不一定说应该达到100％的覆盖率，但是应该进行代码覆盖驱动的单元测试，因为它是一种更直观的方式来理解和暴露存在的代码行为。 只需查看它就可以为您提供有关如何重构代码以实现单一责任原则和关注点分离的新想法。

Answer 4

你可以让你的会话模拟抛出异常，但几乎没有必要测试一个catch是否有效。

如果更新引发异常但是在直觉级别上，我认为这样做太过分了，那么编写测试以检查事务是否已回滚并没有错。

也许更精心的案例是值得的。

另外请注意，您是否不会回滚任何类型的异常？

Answer 5

如果在Commit（）之前调用Displose（），我希望事务将是Rollback，因此你是否需要catch？

至于其他情况，如果你的捕获更多，那么只记录问题，我认为它应该是单元测试。 但是，不要让事实上你不能做利润单元测试阻止你做一些单元测试。

Answer 6

从异常名称（HibernateException）我会认为这不是一个例外情况。 所以它可能在正常操作期间发生。 如果是这种情况，我会做一个导致异常的测试，以确保它得到妥善处理。

Answer 7

我当然会测试捕获和处理的每个特定异常。 至少你有一些通过你的处理代码的执行路径，这应该给你一些安慰，当你在运行时遇到这样的异常时，没有别的奇怪的事情会发生。

请记住，您只需要测试您想要使用的代码。

Answer 8

我当然希望你能单独测试transaction.Rollback() ，测试会耗尽你能想到的所有可能情况。 但是，如果测试是详尽无遗的，我可能不会费心提出异常，因为处理程序中没有其他内容。