我读了很多的帖子,说服我应该开始写单元测试,我也开始使用依赖注入(Unity)为了更容易嘲笑,但我仍然不知道在什么阶段我应该开始写单元测试和模拟,以及如何或从哪里开始。
测试第一/测试后:
原文链接:https://www.f2er.com/javaschema/282702.html应该注意,作为TDD的一部分的“测试第一”与设计一样多(如果不是更多),因为它是与单元测试。它是一种软件开发技术,它自己的权利 – 写测试结果不断完善的设计。
另一个注意事项:如果从纯单元测试的角度来看,TDD有一个显着的优势,那就是编写一个在TDD时错误的测试要困难得多(虽然不是不可能)。如果事先编写测试,它应该总是失败,因为使测试通过所需的逻辑不存在。如果你之后写测试,逻辑应该在那里,但如果测试被错误或测试错误的东西,它可以通过。
也就是说如果你之前写过一个坏的测试,你可能会得到一个绿灯,当你期望一个红色(所以你知道测试是坏)。如果你之后写了一个坏的测试,你会得到一个绿灯,当你预期一个绿色(不知道坏的测试)。
图书
实用的单元测试书非常值得一看,Roy Osherove的“单元测试的艺术”也是如此。实用的书更狭隘地集中在不同类型的测试输入,你可以尝试找到错误,而TAOUT涵盖了更广泛的话题,如测试双打,策略,可维护性等。它取决于你想要从它。
此外,这里是一个link to a talk Roy Osherove did on unit testing.这是值得一看(所以他记录的一些测试审查视频,因为他指出各种问题和dos / don’ts连同原因为什么)。
如何开始
没有比编写代码更好的了。找到一个相当简单的类,不参考别的东西。然后,开始写一些测试。
总是问自己“我想用这个测试来证明什么?在写它之前,然后给它一个体面的名字(通常涉及被调用的方法,场景和预期的结果,例如在堆栈:“Pop WhenStackIsEmpty ThrowsException”)。
想想你可以抛出的所有输入,不同的方法组合,可能会产生有趣的结果,等等。