unit-testing - 如何开始单元测试或TDD？

Question

我读了很多帖子，这些帖子说服了我应该开始编写单元测试，为了更容易模拟，我也开始使用依赖注入(inject)(Unity)，但我仍然不太确定应该从哪个阶段开始编写单元测试和模拟，以及如何或从哪里开始。

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

单元测试有什么不同的方法或方式吗？

Answer 1

先测试/后测试:

应该指出的是，作为 TDD 的一部分，“测试第一”与设计的关系与与单元测试的关系一样(如果不是更多的话)。它本身就是一种软件开发技术——在不断完善设计的过程中编写测试结果。

另外一点:如果从纯单元测试的角度来看 TDD 有一个显着的优势，那就是在进行 TDD 时编写错误的测试要困难得多(尽管并非不可能)。如果您事先编写测试，它应该总是失败，因为使测试通过所需的逻辑尚不存在。如果您之后编写测试，逻辑应该就在那里，但是如果测试有错误或者测试了错误的东西，那么无论如何它都可能会通过。

即如果您之前编写了一个糟糕的测试，那么当您期望看到红灯时，您可能会得到绿灯(因此您知道测试很糟糕)。如果您事后编写了一个糟糕的测试，那么当您期望绿灯时，您将获得绿灯(不知道糟糕的测试)。

书籍

这本实用的单元测试书籍非常值得一看，Roy Osherove 的《单元测试的艺术》也是如此。这本实用的书更集中于不同类型的测试输入，您可以尝试查找错误，而 TAOUT 涵盖了更广泛的主题，例如测试替身、策略、可维护性等。这取决于你想从中得到什么。

另外，这里有一个 link to a talk Roy Osherove did on unit testing 。值得一看(他录制的一些测试回顾视频也值得一看，因为他指出了各种问题和注意事项以及原因)。

如何开始

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

始终问自己“我想通过此测试尝试并证明什么？”在编写它之前，给它一个合适的名称(通常涉及被调用的方法、场景和预期结果，例如在堆栈上:“Pop WhenStackIsEmpty ThrowsException”)。

想想您可以向其提供的所有输入、可能产生有趣结果的不同方法组合等等。