单元测试 - 不能从理论转向实践

Question

似乎我遇到的每个单元测试示例都非常明显和罐装.像断言x + 3 == 8等等.我只是很难看到我如何单元测试现实世界的东西,比如SQL查询,或者用于表单验证的regEx实际上是否正常工作.

例证:我正在开发两个由DB驱动的ASP.NET MVC 2站点.我为每个人都有一个测试单元解决方案,但不知道哪种测试会有用.该站点将完成的大部分工作是向数据库写入数据,或从数据库中检索和组织数据.我只是测试各种查询是否成功访问了数据库？我如何测试正确性(例如,数据被写入正确的字段,或正确检索的数据)？

我只是很难将我自己的非正式测试和调试方式转换为更正式的断言(x)类测试.

Answer 1

为了使单元测试可行,您的代码必须适用于内聚和解耦的原则.实际上,它会在您应用它时强制执行这些原则.这意味着,如果您的代码没有得到很好的考虑(即正确应用OO设计原则),单元测试将几乎不可能和/或无用.

因此,考虑这个问题的最好方法可能是"如何将我的应用程序的所有工作分成更小,更有凝聚力的代码片段,只做一两件事并使用它们来组合我的应用程序？"

在你根据自己对代码的看法进行内化之前,单元测试可能没有意义.

Answer 2

首先，问问自己“为什么我的真实代码很难编写单元测试？” 也许答案是您的实际代码做了太多事情。如果您有一个代码模块，其中充满了“new”语句、“if”语句和“switch”语句以及巧妙的数学语句和数据库访问，那么编写一个测试将会很痛苦，更不用说充分测试逻辑和数学。但是，如果您将“新”语句提取到工厂方法中，则可以轻松提供模拟对象进行测试。如果您将“if”子句和“switch”语句提取到状态机模式中，则不会有那么多组合需要测试。如果删除对外部数据提供程序对象的数据库访问，则可以提供简单的测试数据来执行数学语句。现在，您正在测试对象创建、状态转换和数据访问，所有这些都与您巧妙的数学语句分开。所有这些步骤都通过简化而变得更加容易。

代码难以测试的一个关键原因是它包含“内部依赖项”，例如它创建的依赖项或对库的依赖项。如果你的代码显示“Foo theFoo = new Foo();” 你不能轻易地替换 MockFoo 来进行测试。但是，如果您的构造函数或方法要求传入 theFoo 而不是构造自身，则您的测试工具可以轻松传入 MockFoo。

当你编写代码时，问问自己“我怎样才能为这段代码编写单元测试？” 如果答案是“很难”，您可能会考虑更改代码以使其更易于测试。这样做的作用是使您的单元测试成为代码的第一个实际使用者 - 您通过编写测试来测试代码的接口。

通过更改接口以使它们更易于测试，您会发现自己更好地遵守“紧密内聚”和“松散耦合”的面向对象原则。

单元测试不仅仅是测试。编写单元测试实际上可以改善您的设计。沿着这条路走得更远一点，你最终会得到测试驱动开发。

祝你好运！