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

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


当前回答

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

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

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

其他回答

首先,无论是谈论单元测试还是其他类型的自动化测试(集成、加载、UI测试等),与您所建议的关键区别在于它是自动化的、可重复的,并且不需要消耗任何人力资源(=没有人需要执行测试,它们通常按下按钮就可以运行)。

我在FoxForward 2007参加了一个关于单元测试的演讲,被告知永远不要对任何与数据相关的东西进行单元测试。毕竟,如果您在实时数据上进行测试,结果是不可预测的,如果您不在实时数据上进行测试,那么实际上并不是在测试您所编写的代码。不幸的是,这是我最近编写的大部分代码。: -)

最近,当我编写一个保存和恢复设置的例程时,我确实尝试了TDD。首先,我验证了是否可以创建存储对象。然后,它有我需要调用的方法。然后,我可以称之为。然后,我可以给它传递参数。然后,我可以给它传递特定的参数。依此类推,直到我最终验证它将保存指定的设置,允许我更改它,然后为几种不同的语法恢复它。

我没看完,因为我现在需要例行公事,但这是一个很好的练习。

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

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

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

I think the point that you don't understand is that unit testing frameworks like NUnit (and the like) will help you in automating small to medium-sized tests. Usually you can run the tests in a GUI (that's the case with NUnit, for instance) by simply clicking a button and then - hopefully - see the progress bar stay green. If it turns red, the framework shows you which test failed and what exactly went wrong. In a normal unit test, you often use assertions, e.g. Assert.AreEqual(expectedValue, actualValue, "some description") - so if the two values are unequal you will see an error saying "some description: expected <expectedValue> but was <actualValue>".

总之,单元测试将使测试更快,对开发人员来说更舒服。您可以在提交新代码之前运行所有的单元测试,这样就不会中断同一项目中其他开发人员的构建过程。

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

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

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

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