我看到很多问题都在问“如何”用一种特定的语言进行单元测试,但没有人问“什么”、“为什么”和“什么时候”。

是什么? 它对我有什么用? 我为什么要用它? 什么时候用(什么时候不用)? 有哪些常见的陷阱和误解


当前回答

测试驱动开发在某种程度上取代了单元测试这个术语。作为一个老手,我会提到它的更一般的定义。

单元测试还意味着测试一个较大系统中的单个组件。这个组件可以是dll、exe、类库等。它甚至可以是多系统应用程序中的单个系统。因此,单元测试最终是对一个更大系统的单个部分进行测试。

然后,您可以通过测试所有组件如何一起工作来进行集成测试或系统测试。

其他回答

如果你想使用Kent Beck推广的TDD方法开发项目,像NUnit、xUnit或JUnit这样的库是必须的:

你可以阅读《测试驱动开发介绍》(TDD)或Kent Beck的《测试驱动开发:举例说明》。

然后,如果你想确保你的测试覆盖了代码中“好的”部分,你可以使用NCover、JCover、PartCover或其他软件。它们会告诉你代码的覆盖率。取决于你对TDD的熟练程度,你会知道你是否已经很好地练习了它:)

单元测试,粗略地说,就是在与测试代码隔离的情况下测试代码。我想到的直接优势是:

测试的运行变得自动化和可重复 您可以在更细粒度的级别上进行测试,而不是通过GUI进行点击测试

请注意,如果您的测试代码写入文件、打开数据库连接或在网络上执行某些操作,则更适合将其归类为集成测试。集成测试是一件好事,但不应将其与单元测试混淆。单元测试代码应该简短、简单且易于执行。

另一种看待单元测试的方法是先编写测试。这被称为测试驱动开发(简称TDD)。TDD带来了额外的优势:

您不需要编写推测性的“我将来可能需要这个”代码——只要能够通过测试即可 您编写的代码总是会被测试覆盖 通过先编写测试,您不得不考虑如何调用代码,从长远来看,这通常会改善代码的设计。

如果你现在还没有做单元测试,我建议你现在就开始做。找一本好书,实际上任何xUnit-book都可以,因为它们之间的概念可以很好地转换。

有时编写单元测试会很痛苦。当出现这种情况时,试着找个人来帮助你,并抵制住“只写该死的代码”的诱惑。单元测试很像洗碗。这并不总是令人愉快的,但它让你的比喻厨房保持干净,而你真的希望它干净。:)


编辑:我想到了一个误解,虽然我不确定它是否普遍。我曾听一个项目经理说过,单元测试让团队把所有的代码都写了两次。如果它看起来和感觉是那样的,那么,你做错了。编写测试通常不仅可以加快开发速度,而且还为您提供了一个方便的“现在我完成了”指示器,否则您就不会有这个指示器。

使用Testivus。你需要知道的都在那里:)

如果给你一堆垃圾,你似乎陷入了一种永久的清理状态,你知道任何新功能或代码的添加都会破坏当前的设置,因为当前的软件就像一个纸牌屋,你会怎么做? 那么我们如何进行单元测试呢?

从小事开始。我刚加入的项目直到几个月前才开始进行单元测试。当覆盖率如此之低时,我们将简单地选择一个没有覆盖率的文件并单击“添加测试”。

现在我们已经达到了40%以上,我们已经成功地摘走了大部分容易摘到的果实。

(最好的部分是,即使在这样低的覆盖率水平上,我们已经遇到了许多代码做错误事情的实例,并且测试发现了它。这是促使人们增加更多测试的巨大动力。)

单元测试是关于编写测试应用程序代码的代码。

名称的Unit部分是关于一次测试小单元代码(例如一个方法)的意图。

xUnit是用来帮助测试的——它们是帮助测试的框架。其中一部分是自动测试运行器,它会告诉您哪些测试失败,哪些测试通过。

它们还可以在每个测试之前设置您需要的公共代码,并在所有测试完成后将其删除。

您可以使用一个测试来检查是否抛出了预期的异常,而不必自己编写整个try catch块。