问自动化单元测试-为什么？什么？哪一个?

EN

为什么我们需要自动化的单元测试？它有多有效？

自动化的单元测试是非常有价值的，首先也是最重要的，因为它是自动化的(通常，当它是自动化的时候，我们才认为它是‘单元测试’)。随着应用程序大小的增加，手动测试整个应用程序可能需要几个小时甚至几个星期。即使是测试应用程序的一小部分也需要时间，而且容易出错。除非你是自闭症患者，否则，如果你必须反复做一次又一次的手工测试，你将无法集中精力100%正确地执行每一次手动测试。

在敏捷开发中，我们使用快速反馈的概念:你越早得到关于你所做的事情是对还是错的反馈，你就越有效率。我们都会犯错误，但在犯错30秒后发现和修复一个错误比几天或几个星期后要便宜得多。这就是为什么自动化测试如此重要的原因。

虽然您可以在许多级别上进行自动化测试，但单元测试是实现的最有效的类型。它可能是最难理解和掌握的测试规程，但它比任何其他类型的测试都要健壮得多。

如果我想要开始进行自动化的单元测试，请使用。我该从哪里开始？(听说过nunit)

首先，您需要学习一些单元测试基础。Roy的书单元测试的艺术是一个很好的介绍。

谈到框架，NUnit已经存在了很长一段时间，但是它也存在一些固有的问题。

如果您已经拥有或Team，则有一个内置的单元测试框架，通常称为MSTest。大多数人不喜欢这个框架，但就我个人而言，我觉得它是足够的。IDE集成运行良好，但API可能更好。

如果您正在寻找一个免费的、开放源码的单元测试框架，我建议使用xUnit.net，这是一个更现代的框架。

在设计类以方便自动化单元测试时，我需要记住什么吗？

是的，每个类都应该能够单独使用。这可能很难通过预先设计来完成，或者如果您试图将单元测试改进到现有代码上，但是如果您采用测试驱动开发(TDD)，则应该会或多或少地自然地实现。

C#对自动单元测试有内置的支持吗？

不，C#只是一种语言，但正如我前面提到的，某些版本的Visual有MSTest。

我们也可以用自动化的单元测试来测试GUI，还是仅仅是业务逻辑？

单元测试GUI往往非常脆弱(也就是说，测试维护非常高)，因此通常不是一个好主意。

然而，有许多设计模式可以帮助您将所有GUI逻辑提取到可测试类中: Modev-View-Controller、Model-View-Presenter、Application Controller、Model-View-ViewModel等。

您可以通过这样的接口执行整个应用程序的自动化测试，只绕过GUI呈现部分。这种测试被称为皮下测试，但被认为是集成测试，而不是单元测试。

听说过模拟框架。它们也用于单元测试吗？

动态模拟库仅用于单元测试。

一些好的和受欢迎的是

• 莫克
• 犀牛毛

• 为什么我们需要自动化的单元测试？它有多有效？

隔离程序的各个部分，并证明它们是“正确的”。如果您愿意的话，它们是一个契约，说明代码应该如何运行。有了这一点，他们可以快速和经常地告诉您，代码是否正确运行。

单元测试使程序员能够更容易地更改代码，具有更多的信心和更少的副作用。它促进/支持代码的重构，没有单元测试的代码可能是危险的。考虑到这一切，我发现单元测试将使您的代码更好。

我认为它们是有效的，但我会承认这是学习曲线的一部分。直到你变得真正擅长它(在我的头脑中，我仍然是一个初学者)，你会经常错过一些东西，但我发现它仍然比我做了太久的手工测试要好得多。我在单元测试中发现了几乎即时的好处。在我的第一个项目中，我发现我节省了大量的时间，因为我不需要手动测试，实际上，当我正在编写的代码导致其他地方的测试失败时，我还不止一次感到惊喜，我甚至没想到要手动重新测试。

• 如果我想开始进行自动化的单元测试。我该从哪里开始？(听说过nunit)

单位好，MbUnit好。要开始阅读，阅读并在阅读中做摘录。关于单元测试、测试驱动开发(TDD)和重构的网站和博客。对象导师有一个关于TDD的很好的系列。然后，在某个时候选择一些您已经拥有的代码，并尝试它。

我建议的书籍-测试驱动开发，测试驱动开发，实用指南，单元测试的艺术，重构(马丁福勒)，重构工作簿，重构模式，清洁代码，我相信还有其他。

我在列表中有重构书籍，因为我已经找到了重构工作的技术，帮助处理单元测试。

• 在设计类以方便自动化单元测试时，我需要记住什么吗？

我提到的许多书都会讨论这个问题。答案是肯定的和不是的。通常，更好设计的类具有较少的依赖项，因此更容易进行测试。这只是一个好的设计，但它恰好使测试更容易。对于是否应该更改代码以使其更易于测试，存在着一些争论。我应该向你倾斜。在这一点上，对我来说，我的代码在过去并没有包含很多“好的设计”的想法，所以对我来说，这个TDD之旅是提高我的意识和好的设计水平，在我的代码中，这部分是为了想要做TDD。

• C#对自动化单元测试有内置的支持吗？

如果你有VS 2008专业，是的，或团队系统，但我很自然地假设你没有。

• 我们也可以用自动化的单元测试来测试GUI，还是仅仅是业务逻辑？

是的，外面有几种工具。瓦丁是一个在脑海中浮现的人。

• 听说过模拟框架。它们也用于单元测试吗？

是。它们允许模拟/测试非常复杂的对象，您不能轻松地进行单元测试。

在我沿着TDD道路前进的过程中，我一开始故意忽略了嘲笑。对我来说，我想更好地理解为什么需要它们，以及在没有它们的情况下如何使用它们，并在编写代码时亲眼看到我将被传统的TDD技术所困住。

另一本我发现有很大用处的书，虽然读起来很伤脑筋，但却有效地使用了遗产代码。它确实向你展示了，对未受过训练的人来说，看似无辜的代码会让生活变得非常艰难。

第1点)它为您提供了一个持续的概述，什么工作和什么不起作用。一旦您更改了一个简单的函数，如果这个更改破坏了什么，您就会得到结果。此外，你可以在以后重构你的整个应用程序，至于你的单元测试都是绿色的，一切都很好。这一点是非常重要的。或者你曾经做过一个从未被重构过的项目？

第2点) NUnit是一个很好的起点，但是还有其他几个单元测试框架。此外，我建议您看看CruiseControl或其他持续集成工具，这些工具可以为开发人员带来大量的工作。

好吧，有些人肯定会告诉你该做什么和不做什么。就我的单元测试背景而言，它仅限于用于嵌入式设备，我们还有相当多的差异。

C#是一种编程语言，而不是测试框架。.Net至少有一个可以在单元测试期间提供帮助的属性，即InternalsVisibleTo-属性，用于使内部类和方法对一种特定类型公开。

5)如果你有一个设计良好的应用程序，你不必测试你的gui。想想看:你的gui没有密码。用户可以按下的每个按钮都映射到控制器。用户可以提供的每一个输入都交给控制器。那你要在你的盖伊里测试什么？您所要做的就是让您的控制器测试和工作良好。使用这个MVVM/MVC/WhatElseArchitecture，一方面是一个设计良好的应用程序，另一方面是一个易于测试的应用程序。