如何开始单元测试或 TDD? [英] How to start unit testing or TDD?

问题描述

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

I read a lot of posts that convinced me I should start writing unit test, I also started to use dependency injection (Unity) for the sake of easier mocking, but I'm still not quite sure on what stage I should start writing the unit tests and mocks, and how or where to start.

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

Would the preferred way be writing the unit tests before the methods as described in the TDD methodology?

是否有任何不同的单元测试方法或方式?

Is there any different methodology or manner for unit testing?

推荐答案

先测试/后测试:

应该注意，作为 TDD 的一部分，先测试"与设计的关系与单元测试的关系一样多(如果不是更多的话).它本身就是一种软件开发技术——编写测试会导致设计的不断改进.

It should be noted that 'test first' as part of TDD is just as much (if not more) to do with design as it is to do with unit testing. It's a software development technique in its own right -- writing the tests results in a constant refining of the design.

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

On a separate note: If there is one significant advantage to TDD from a pure unit testing perspective, it is that it is much harder (though not impossible) to write a test that's wrong when doing TDD. If you write the test beforehand, it should always fail because the logic required to make the test pass does not yet exist. If you write the test afterwards, the logic should be there, but if the test is bugged or is testing the wrong thing, it may pass regardless.

即如果你之前写了一个糟糕的测试，当你期望一个红色的时候你可能会得到一个绿灯(所以你知道这个测试很糟糕).如果你之后写了一个糟糕的测试，你会在你预期是绿色的时候得到一个绿灯(不知道这个糟糕的测试).

I.e. if you write a bad test before, you may get a green light when you expect a red (so you know the test is bad). If you write a bad test afterwards, you will get a green light when you expected a green (unaware of the bad test).

书籍

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

The pragmatic unit testing book is well worth a look, as is Roy Osherove's "The Art of Unit Testing". The pragmatic book is more narrowly focussed on the different types of test inputs you can try to find bugs, whereas TAOUT covers a wider spread of topics such as test doubles, strategies, maintainability etc. Either book is good; it depends what you want from it.

另外，这里有一个链接到一个谈话Roy Osherove 做了单元测试.值得一看(他录制的一些测试评论视频也是如此，因为他指出了各种问题和注意事项以及原因).

Also, here's a link to a talk Roy Osherove did on unit testing. It's worth a watch (so are some of the test review videos he recorded, as he points out various problems and dos/don'ts along with reasons why).

如何开始

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

There's nothing better than writing code. Find a fairly simple class that doesn't reference much else. Then, start writing some tests.

总是问自己我想通过这个测试尝试和证明什么?"在你写它之前，然后给它一个像样的名字(通常涉及被调用的方法、场景和预期结果，例如在堆栈上:Pop WhenStackIsEmpty ThrowsException").

Always ask yourself "what do I want to try and prove with this test?" before you write it, then give it a decent name (usually involving the method being called, the scenario and the expected result, e.g. on a stack: "Pop WhenStackIsEmpty ThrowsException").

想想你可以投入的所有投入，可能产生有趣结果的不同方法组合等等.

Think of all the inputs you can throw at it, different combinations of methods that may yield interesting results and so forth.

这篇关于如何开始单元测试或 TDD?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！