参数异常应该进行单元测试吗

参数异常应该进行单元测试吗

本文介绍了参数异常应该进行单元测试吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我知道这个问题与之前发布的其他问题非常相似,但是我想以适当的方式讨论此主题。

I know this question is pretty similar to others that have been posted before but I would like to discuss this topic in a proper way.

您认为明显异常应该进行单元测试吗?

Do you think that the "obvious" exception should be unit tested?

对于明显异常,我的意思是例如在我们的业务逻辑存在的情况下,由于空参数或空字符串或负数导致的异常我们的单元使我们很明显,这些异常将始终在任何其他操作之前在我们方法的开头抛出。

With obvious exception I mean for example exceptions due to null arguments or empty strings or negative numbers in situations where we the business logic of our unit make us obvious that these exceptions will always be thrown at the beginning of our method(s) before any other operation.

换句话说,我说的是在违反集体合同最简单的部分之后应该引发的异常。

In other words I'm speaking of the exceptions that should be thrown after the violation of the simplest part of a class contract.

谢谢您的意见。

推荐答案

绝对。您称它们为显而易见的,但记住要验证前提条件并没有明显的意义。实际上,我职业生涯中看到的大多数代码并没有采取明显的步骤来防止以后出现混乱。

Absolutely. You call them "obvious," but there's nothing obvious about remembering to verify pre-conditions. In fact, most of the code I've seen in my career does not take this obvious step to prevent mayhem later on.

尽管您在库代码中看到了很多该代码是为公共消费,重用等编写的,大多数开发人员常常记得将这样的检查放入自己的代码中。在测试驱动的环境中,对此类条件进行测试会迫使开发人员在其公共方法上正确验证输入参数。

While you see this a lot in library code that's written for public consumption, reuse, etc., remembering to put such checks into one's own code often seems to slip by most developers. In a test-driven environment, putting tests for such conditions forces developers to properly validate input parameters on their public methods.

而且,公平地说,只要有机会,编写另一个测试并查看绿色栏,我很高兴。 :)

And let's be fair... any chance I get to write another test and see the green bar, I'm happy. :)

这篇关于参数异常应该进行单元测试吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-22 19:00