单元测试新手，如何编写出色的测试? [英] New to unit testing, how to write great tests?

问题描述

我对单元测试领域还很陌生，本周我刚刚决定为我现有的应用添加测试覆盖率.

I'm fairly new to the unit testing world, and I just decided to add test coverage for my existing app this week.

这是一项艰巨的任务，主要是因为要测试的类数量很多，而且还因为编写测试对我来说是全新的.

This is a huge task, mostly because of the number of classes to test but also because writing tests is all new to me.

我已经为很多类编写了测试，但现在我想知道我是否做得对.

I've already written tests for a bunch of classes, but now I'm wondering if I'm doing it right.

当我为一个方法编写测试时，我有一种第二次重写我已经在方法本身中编写的内容的感觉.
我的测试似乎与方法紧密相关(测试所有代码路径，期望多次调用某些内部方法，并带有某些参数)，似乎如果我重构该方法，测试将失败，即使方法的最终行为没有改变.

When I'm writing tests for a method, I have the feeling of rewriting a second time what I already wrote in the method itself.
My tests just seems so tightly bound to the method (testing all codepath, expecting some inner methods to be called a number of times, with certain arguments), that it seems that if I ever refactor the method, the tests will fail even if the final behavior of the method did not change.

这只是一种感觉，前面说了，我没有测试经验.如果那里有一些更有经验的测试人员可以就如何为现有应用编写出色的测试给我建议，我将不胜感激.

This is just a feeling, and as said earlier, I have no experience of testing. If some more experienced testers out there could give me advices on how to write great tests for an existing app, that would be greatly appreciated.

我很想感谢 Stack Overflow，我在不到 15 分钟的时间内提供了很好的输入，回答了我刚刚阅读的更多小时的在线阅读时间.

Edit : I would love to thank Stack Overflow, I had great inputs in less that 15 minutes that answered more of the hours of online reading I just did.

推荐答案

我的测试似乎与方法紧密相关(测试所有代码路径，期望多次调用某些内部方法，并带有某些参数)，似乎如果我重构该方法，测试将失败即使方法的最终行为没有改变.

My tests just seems so tightly bound to the method (testing all codepath, expecting some inner methods to be called a number of times, with certain arguments), that it seems that if I ever refactor the method, the tests will fail even if the final behavior of the method did not change.

我认为你做错了.

单元测试应该:

• 测试一种方法
• 为该方法提供一些特定的参数
• 测试结果是否符合预期

它不应该查看方法内部以了解它在做什么，因此更改内部结构不应导致测试失败.您不应直接测试是否正在调用私有方法.如果您有兴趣了解是否正在测试您的私有代码，请使用代码覆盖工具.但不要对此着迷:100% 的覆盖率不是必需的.

It should not look inside the method to see what it is doing, so changing the internals should not cause the test to fail. You should not directly test that private methods are being called. If you are interested in finding out whether your private code is being tested then use a code coverage tool. But don't get obsessed by this: 100% coverage is not a requirement.

如果您的方法调用其他类中的公共方法，并且这些调用由您的接口保证，那么您可以使用模拟框架来测试这些调用是否正在进行.

If your method calls public methods in other classes, and these calls are guaranteed by your interface, then you can test that these calls are being made by using a mocking framework.

您不应使用方法本身(或它使用的任何内部代码)来动态生成预期结果.预期结果应该硬编码到您的测试用例中，以便在实现更改时它不会更改.下面是一个单元测试应该做什么的简化示例:

You should not use the method itself (or any of the internal code it uses) to generate the expected result dynamically. The expected result should be hard-coded into your test case so that it does not change when the implementation changes. Here's a simplified example of what a unit test should do:

testAdd()
{
    int x = 5;
    int y = -2;
    int expectedResult = 3;
    Calculator calculator = new Calculator();
    int actualResult = calculator.Add(x, y);
    Assert.AreEqual(expectedResult, actualResult);
}

请注意，不会检查结果的计算方式 - 仅检查结果是否正确.继续添加越来越多的简单测试用例，直到您覆盖了尽可能多的场景.使用您的代码覆盖率工具查看您是否遗漏了任何有趣的路径.

Note that how the result is calculated is not checked - only that the result is correct. Keep adding more and more simple test cases like the above until you have have covered as many scenarios as possible. Use your code coverage tool to see if you have missed any interesting paths.

这篇关于单元测试新手，如何编写出色的测试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！