我正在阅读单元测试的艺术”,并且有一个特定的段落我不确定。
“您可能希望避免使用基类而不是接口的原因之一是生产代码中的基类可能已经(并且可能具有)您必须了解并覆盖的内置生产依赖项. 这使得实现派生类进行测试比实现一个接口更难,这让你确切地知道底层实现是什么,并让你完全控制它。
有人可以给我一个内置生产依赖的例子吗?
谢谢
我正在阅读单元测试的艺术”,并且有一个特定的段落我不确定。
“您可能希望避免使用基类而不是接口的原因之一是生产代码中的基类可能已经(并且可能具有)您必须了解并覆盖的内置生产依赖项. 这使得实现派生类进行测试比实现一个接口更难,这让你确切地知道底层实现是什么,并让你完全控制它。
有人可以给我一个内置生产依赖的例子吗?
谢谢
我对此的解释基本上是任何你无法控制底层实现但仍然依赖它的地方。这可能在您自己的代码或第三方库中。
就像是:
class MyClass : BaseConfigurationProvider
{
}
abstract class BaseConfigurationProvider
{
string connectionString;
protected BaseConfigurationProvider()
{
connectionString = GetFromConfiguration();
}
}
这依赖于从哪里返回连接字符串,可能是配置文件,也可能是随机文本文件 - 无论哪种方式,对于MyClass
.
而给定一个接口也是一样的:
class MyClass : IBaseConfigurationProvider
{
string connectionString;
public MyClass(IBaseConfigurationProvider provider)
{
connectionString = provider.GetConnectionString();
}
}
interface IBaseConfigurationProvider
{
string GetConnectionString();
}
您至少可以完全控制实现,并且使用接口意味着可以在单元测试期间使用实现的测试版本,或者您可以将依赖项注入到消费类中(就像我在上面所做的那样)。在这种情况下,依赖于解析连接字符串的需要。测试可以提供不同的字符串或空字符串。
我能想到的一个例子是在 asp.net 中使用 Session 变量(我是一个 .net 人)
,因为你无法控制 asp.net 如何填充会话变量,你不能简单地通过制作一个测试用例来测试它将不得不以某种方式覆盖它或制作一个模拟对象
,这是因为在测试时所有上下文和 cookie 都不存在