如何启动单元测试或TDD?

先测试/后测试:

应该注意的是,作为TDD的一部分,“测试优先”与设计的关系与单元测试的关系一样大(如果不是更多的话)。它本身就是一种软件开发技术——编写测试结果以不断改进设计。

另请注意:如果从纯单元测试的角度来看,TDD有一个显著的优势,那就是编写一个在进行TDD时出错的测试要困难得多(虽然不是不可能)。如果您事先编写测试,它应该 总是 失败,因为使测试通过所需的逻辑尚不存在。如果您随后编写测试,那么逻辑 应该

也就是说,如果你之前写了一个不好的测试,当你期望一个红色时,你可能会得到一个绿灯(这样你就知道测试是不好的)。如果您在之后编写了一个错误的测试,那么当您期望一个绿色(不知道错误的测试)时,您将得到一个绿灯。

书

link to a talk Roy Osherove did on unit testing . 这值得一看(他录制的一些考试复习视频也值得一看,因为他指出了各种问题和注意事项以及原因)。

如何开始

没有什么比写代码更好的了。找到一个不引用太多其他内容的相当简单的类。然后,开始编写一些测试。

想想你能投入的所有投入,不同的方法组合可能会产生有趣的结果等等。

如果你对单元测试感兴趣,最好的学习方法就是尝试一下。您可能会首先开始编写集成测试,但这很好。当它们看起来太难维护或太多的工作需要编写时,请阅读更多关于测试类型(单元测试、功能测试、集成测试)的内容,并尝试了解其中的差异。

this .

更多关于单元测试的信息

测试不需要配置。

在C#和visual studio中,我发现以下过程非常有用:

2. 在生产代码中创建类并适当地命名。

3. 选择要实现的类的一种行为,并为其创建一个方法存根。使用VisualStudio创建空方法存根是小菜一碟。

5. 编译并让测试运行程序显示红色条!

7. 转到下一个行为。

对于该程序,有两件事非常重要:

• 考虑类/对象的行为。这将使测试和生产代码行为以行为为中心,这是考虑类/对象的一种非常自然的方法。

先测试还是不先测试?

我发现通常很难将测试改装成现有的生产代码。在大多数情况下,这是由于与其他对象的复杂依赖关系造成的,此时需要初始化正在测试的对象。TDD通常避免这种情况,因为您希望在测试用例中尽可能少地初始化对象。这将导致非常松散的耦合。

当我改装测试时,最麻烦的工作就是初始化测试对象。此外,由于复杂的依赖关系,断言可能需要大量工作。为此,您需要更改生产代码并打破依赖关系。通过正确地使用依赖项注入,这不应该是一个问题。

是的 首选 进行TDD的方法是首先编写测试(正如名称所暗示的那样) ).当您开始使用TDD时,可能很难知道从何处开始编写测试,因此我建议您对此采取务实态度。毕竟,我们工作中最重要的部分是交付工作代码,而不是如何编写代码。

史蒂夫·桑德森(Steve Sanderson)在TDD最佳实践方面写得很好。

http://feeds.codeville.net/~r/SteveCodeville/~3/DWmOM3O0M2s/

http://www.asp.net/learn/mvc-videos/ 在页面底部查找“店面”系列。

MOQ 似乎是最近最热门的嘲弄框架,你可能也想看看

总之,试着编写一个测试来验证您正试图归档的东西,然后实现代码使其工作。

这种模式称为红-绿-重构。还要尽最大努力减少依赖关系,以便您的测试可以集中在一个组件上。

就我个人而言,我使用VisualStudio单元测试。我不是一个铁杆TDD开发人员,但我喜欢做的是:

2. 创建一个单元测试项目,并开始编写单元测试,以满足我试图实现的功能。
5. 重构

我还觉得在现有的代码基础上添加功能非常有用。如果您想要添加一些新特性,首先为您想要添加的内容创建单元测试,逐步检查代码以查看您需要更改的内容,然后执行TDD过程。

Here is a tutorial application (在分支“教程”中)显示要编写的测试类型。在该教程中,您编写代码以通过预定义的测试用例,从而进入节奏,然后编写自己的测试。自述文件包含说明。它是用Java编写的,但是您可以很容易地将它改编成C。

之前 单元

嘲弄和嘲弄都有自己的位置;它们是你工具箱里的好工具。但是他们比典型的测试新手需要更复杂、更深入的理解。然而,首先编写测试就和听起来一样简单。所以它更容易接受,而且它本身就很强大(没有mock和DI)。首先编写模拟自由测试,比尝试从模拟开始,您将获得更早、更容易的胜利, 和 和 我一下子就忘了。

首先从测试开始;当您对它非常满意时,当您的代码告诉您需要模拟时,

我推荐TDD—测试驱动开发。这可以确保你有很好的覆盖范围,但它也会将你的注意力集中在正确的地方和问题上。

因此,对于每一项新开发,您要做的第一件事就是编写一个单元测试——即使您没有一个类要测试。

在开发过程中继续编写单元测试,然后最终测试将通过,功能将完成。

扩展SteveFreeman的答案:DaveAstel的书叫做“测试驱动开发-实践指南”。如果您正在编写的应用程序是GUI应用程序,那么这应该会有所帮助。我读了Kent Beck的书,但我不知道如何用TDD启动一个项目。Astel的书测试使用故事从头到尾驱动一个完整的非平凡GUI应用程序。它帮助我从TDD开始,它告诉我从哪里开始,如何开始。

测试驱动开发可能会让初学者感到困惑,我在学习TDD时读过很多书,它们会教你如何为计算器类编写单元测试,但对于构建更以数据为中心的真实应用程序来说,帮助似乎很少。对我来说,突破是当我理解了什么是行为驱动开发或BDD,以及如何从外部开始进行测试时。现在我可以简单地建议您关注您的应用程序行为,并编写单元测试来验证它。TDD和BDD之间有很多争论,但我认为在每个级别编写良好的自动化测试都会增加价值,要编写它们,我们需要关注行为。

哈迪·哈里里在这里有一个很好的职位 http://hadihariri.com/2012/04/11/what-bdd-has-taught-me/

我还写了一些关于这个主题的文章,我觉得这将有助于理解与TDD相关的所有概念

http://codecooked.com/introduction-to-unit-testing-and-test-driven-development/

http://codecooked.com/different-types-of-tests-and-which-ones-to-use/

Pragmatic Unit Testing in C# with NUnit . 它有关于开始编写测试和构建代码的全面信息,以使其更易于单元测试。

如果您以前没有编写过单元测试,那么只需选择一些类并开始编写单元测试,然后继续开发更多的单元测试。

一旦您熟悉了如何编写单元测试,就可以尝试使用TDD。

我更喜欢KentBeck的方法,这在《示例测试驱动开发》一书中有很好的解释。

TDD唯一的实际问题是“重构”(我们也需要重构测试代码)需要很多时间。

我认为Dave Astels的书仍然是最好的介绍之一。它是针对Java的,但您应该能够进行翻译。