如何写好单元测试？ [英] How to write good Unit Tests?

问题描述

任何人都可以建议书或材料学习单元测试吗？

Could anyone suggest books or materials to learn unit test?

有些人认为没有单元测试的代码是旧代码。如今，测试驱动开发是轻松管理大型软件项目的方法。我喜欢C ++很多，我自己学习，没有任何正规教育。我从来没有看过单元测试之前，所以感到遗憾。我认为单元测试是重要的，从长远来看将是有益的。我将感谢任何关于这个主题的帮助。

Some people consider codes without unit tests as legacy codes. Nowadays, Test Driven Development is the approach for managing big software projects with ease. I like C++ a lot, I learnt it on my own without any formal education. I never looked into Unit Test before, so feel left out. I think Unit Tests are important and would be helpful in the long run. I would appreciate any help on this topic.

我主要关注的是：

1. 单元测试？是否是应该分析的测试用例的全面列表？所以让我们说我有一个名为复数的类，其中包含一些方法（让我们说找到共轭，重载的赋值运算符和重载的乘法运算符。这种类的典型测试用例应该是什么？选择测试用例？

1. What is a Unit Test? Is it a comprehensive list of test cases which should be analyzed? So lets us a say i have a class called "Complex Numbers" with some methods in it (lets says finding conjugate, an overloaded assignment operator and an overloaded multiplication operator. What should be typical test cases for such a class? Is there any methodology for selecting test cases?

有没有框架可以为我创建单元测试，或者我必须为测试编写自己的类吗？ Test在Visual Studio 2008中，但从来没有工作。

Are there any frameworks which can create unit tests for me or i have to write my own class for tests? I see an option of "Test" in Visual Studio 2008, but never got it working.

Units测试的标准是什么？

What is the criteria for Units tests? Should there be a unit test for each and every function in a class? Does it make sense to have Unit Tests for each and every class?

推荐答案

一个重要的一点（我在开头没有意识到的），单元测试是一种可以单独使用的测试技术，而不需要应用完整的测试驱动方法。

An important point (that I didn't realise in the beginning) is that Unit Testing is a testing technique that can be used by itself, without the need to apply the full Test Driven methodology.

例如，您要通过向问题区域添加单元测试来改进旧版应用程序，或者想要在现有应用程序中查找错误。现在你编写一个单元测试来暴露问题代码，然后修复它。这些是半测试驱动的，但可以完全适合您当前的（非TDD）开发过程。

For example, you have a legacy application that you want to improve by adding unit tests to problem areas, or you want to find bugs in an existing app. Now you write a unit test to expose the problem code and then fix it. These are semi test-driven, but can completely fit in with your current (non-TDD) development process.

我发现有用的两本书是：

Two books I've found useful are:

在Microsoft .NET中测试驱动的开发

非常熟悉测试驱动

使用C＃和nUnit的实用单元测试

它直接指向什么单元

回应您的观点：

1. 单元测试，实际上是一个类中的单一方法，只包含足够的代码来测试应用程序的一个方面/行为。因此，你将经常有很多非常简单的单元测试，每个测试一小部分你的应用程序代码。例如，在nUnit中，创建一个包含任意数量测试方法的TestFixture类。关键点是测试测试一个单位的代码，即尽可能小的（敏感）单位。

1. A Unit test, in practical terms is a single method in a class that contains just enough code to test one aspect / behaviour of your application. Therefore you will often have many very simple unit tests, each testing a small part of your application code. In nUnit for example, you create a TestFixture class that contains any number of test methods. The key point is that the tests "test a unit" of your code, ie a smallest (sensible) unit as possible. You don't test the underlying API's you use, just the code you have written.

有些框架可能需要一些工作来避免创建测试类，但我不推荐他们。为了创建实际提供重构安全网的有用的单元测试，除了开发人员把思考放在什么和如何测试他们的代码之外别无选择。如果你开始变得依赖于生成单元测试，很容易将它们看作只是另一个必须完成的任务。

There are frameworks that can take some of the grunt work out of creating test classes, however I don't recommmend them. To create useful unit tests that actually provide a safety net for refactoring, there is no alternative but for a developer to put thought into what and how to test their code. If you start becoming dependent on generating unit tests, it is all too easy to see them as just another task that has to be done. If you find yourself in this situation you're doing it completely wrong.

对于每个类，每个方法等有多少个单元测试，没有简单的规则。 。您需要查看应用程序代码，对复杂性存在的位置进行有根据的评估，并为这些领域编写更多测试。大多数人开始测试公共方法，因为这些方法通常执行私有方法的剩余部分。但是这并不总是这样，有时需要测试私有方法。

There are no simple rules as to how many unit tests per class, per method etc. You need to look at your application code and make an educated assessment of where the complexity exists and write more tests for these areas. Most people start by testing public methods only because these in turn usually exercise the remainder of the private methods. However this is not always the case and sometimes it is necessary to test private methods.

简而言之，即使经验丰富的单元测试人员也开始编写明显的单元测试，然后寻找更清晰的测试一旦他们写了明显的测试。他们不希望在前面进行每个测试，而是在他们到达时添加它们。

In short, even experienced unit testers start by writing obvious unit tests, then look for more subtle tests that become clearer once they have written the obvious tests. They don't expect to get every test up-front, but instead add them as they come to their mind.

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