单元测试 – 如何启动单元测试或TDD?

前端之家收集整理的这篇文章主要介绍了单元测试 – 如何启动单元测试或TDD?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我读了很多的帖子,说服我应该开始写单元测试,我也开始使用依赖注入(Unity)为了更容易嘲笑,但我仍然不知道在什么阶段我应该开始写单元测试和模拟,以及如何或从哪里开始。

首选方法是在TDD方法中描述的方法之前编写单元测试?

单元测试有什么不同的方法方法吗?

测试第一/测试后:

应该注意,作为TDD的一部分的“测试第一”与设计一样多(如果不是更多),因为它是与单元测试。它是一种软件开发技术,它自己的权利 – 写测试结果不断完善的设计。

另一个注意事项:如果从纯单元测试的角度来看,TDD有一个显着的优势,那就是编写一个在TDD时错误的测试要困难得多(虽然不是不可能)。如果事先编写测试,它应该总是失败,因为使测试通过所需的逻辑不存在。如果你之后写测试,逻辑应该在那里,但如果测试被错误或测试错误的东西,它可以通过。

也就是说如果你之前写过一个坏的测试,你可能会得到一个绿灯,当你期望一个红色(所以你知道测试是坏)。如果你之后写了一个坏的测试,你会得到一个绿灯,当你预期一个绿色(不知道坏的测试)。

图书

实用的单元测试书非常值得一看,Roy Osherove的“单元测试的艺术”也是如此。实用的书更狭隘地集中在不同类型的测试输入,你可以尝试找到错误,而TAOUT涵盖了更广泛的话题,如测试双打,策略,可维护性等。它取决于你想要从它。

此外,这里是一个link to a talk Roy Osherove did on unit testing.这是值得一看(所以他记录的一些测试审查视频,因为他指出各种问题和dos / don’ts连同原因为什么)。

如何开始

没有比编写代码更好的了。找到一个相当简单的类,不参考别的东西。然后,开始写一些测试。

总是问自己“我想用这个测试来证明什么?在写它之前,然后给它一个体面的名字(通常涉及被调用方法,场景和预期的结果,例如在堆栈:“Pop WhenStackIsEmpty ThrowsException”)。

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

猜你在找的设计模式相关文章