我应该测试方法不抛出异常? [英] Should I test that methods don't throw exceptions?

查看:238
本文介绍了我应该测试方法不抛出异常?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在做我的第一个孩子步骤,单元测试和写(等等)这两种方法:

I'm making my first baby steps with unit testing and have written (among others) these two methods:

    [TestCase]
    public void InsertionSortedSet_AddValues_NoException()
    {
        var test = new InsertionSortedSet<int>();

        test.Add(5);
        test.Add(2);
        test.Add(7);
        test.Add(4);
        test.Add(9);
    }

    [TestCase]
    public void InsertionSortedSet_AddValues_CorrectCount()
    {
        var test = new InsertionSortedSet<int>();

        test.Add(5);
        test.Add(2);
        test.Add(7);
        test.Add(4);
        test.Add(9);

        Assert.IsTrue(test.Count == 5);
    }

NoException 方法真的需要?如果一个异常将被抛出它会在 CorrectCount 方法了。

Is the NoException method really needed? If an exception is going to be thrown it'll be thrown in the CorrectCount method too.

我倾向于把它作为2测试用例(可能重构重复代码的另一种方法),因为测试应该只对一件事的测试,但也许我的理解是错误的。

I'm leaning towards keep it as 2 test cases (maybe refactor the repeated code as another method) because a test should only test for a single thing, but maybe my interpretation is wrong.

推荐答案

要放在最简单的话,IMO测试什么方法不做可能会很滑,你可以拿出更多的场景时,你想想看。周围发生的其他方式寿,声称你的代码的确实你想要它做的东西是单元测试几乎目的。

To put it in the most simple words, IMO testing what method does not do might be very slippery, as you can come up with more and more scenarios when you think about it. Going other way around tho, asserting that your code does stuff you intended it to do is pretty much purpose of unit testing.

有两个简单的问题通常帮我察觉可疑的检验和处理搞清楚测试是否使任何意义:

There are two simple questions which usually help me spotting suspicious test and dealing with figuring out whether test makes any sense:


  • 什么需要的功能部分是测试锻炼?

  • 我可以在测试类有什么简单的改变,打破测试?

请注意,它的极易,以应对其第二次测试这些问题( _CorrectCount )的初衷。我们还没有看到添加方法的代码,但我们可以很可能产生像样的猜测什么可以改变,打破了测试。测试的功能就更加明显。答案是直观,出现快速(这是很好的!)。

Note that it's extremely easy to deal with those questions having second test (_CorrectCount) in mind. We haven't really seen Add method code, but we can most likely produce decent guess what could be changed to break that test. Tested functionality is even more obvious. Answers are intuitive and appear fast (which is good!).

现在让我们试着来回答第一个测试那些问题( _NoException )。这立即引发了新的问题(的是工作代码的实际功能?是不是明摆着的吗?这难道不是暗示?这不正是我们始终追求?为什么有结尾没有说法​​对吗?我该怎么使其失败?的)。对于第二个问题,它甚至更糟 - 打破这一测试可能会要求明确抛出异常......我们都同意是不是要走的路。

Now let's try to answer those questions for the first test (_NoException). It immediately raises new questions (Is working code an actual functionality? Isn't it obvious? Isn't that implied? Isn't that what we always strive for? Why there is no assertion at the end? How can I make it fail?). For the second question it's even worse - breaking that test would probably require explicitly throwing exception... which we all agree is not the way to go.

很简单。第二个测试是的精心编写的单位的测试的完美典范。它的短,它测试单一的东西,它可以很容易想通。首先测试的不是。即使寿它只是作为短(似乎是)简单,它引入了新的问题(虽然它确实应该回答已经说过的 - 确实添加实际添加?是的) - 其结果带来不必要的复杂性

Is simple. Second test is perfect example of well-written unit test. It's short, it tests single thing, it can be easily figured out. First test is not. Even tho it is just as short and (what seems to be) simple, it introduces new questions (while it really should answer already stated ones - Does Add actually add? Yes.) - and as a result brings unnecessary complexity.

这篇关于我应该测试方法不抛出异常?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆