我正在读“单元测试的艺术”,并且有一个特定的段落我不确定。
“您可能希望避免使用基类而不是接口的原因之一是,生产代码中的基类可能已经(并且可能具有)您必须知道的内置生产依赖项这使得实现派生类的测试比实现接口更难,这可以让你准确地知道底层实现是什么,并让你完全控制它。“
有人可以给我一个内置生产依赖的例子吗?
由于
答案 0 :(得分:4)
我对此的解释基本上是你无法控制底层实现的任何东西,但仍然依赖它。这可以在您自己的代码中或在第三方库中。
类似的东西:
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();
}
您至少可以完全控制实现,并且接口的使用意味着可以在单元测试期间使用测试版本的实现,或者您可以将依赖项注入消费类(如上所述)。在这种情况下,依赖性是需要解析连接字符串。测试可以提供不同的或空的字符串。
答案 1 :(得分:0)
我能想到的一个例子是在asp.net(im a .net guy)中使用Session变量
因为你无法控制asp.net如何填充会话变量,你只能通过制作测试用例来测试它,你必须以某种方式覆盖它或制作一个模拟对象
这是因为在测试时所有上下文和cookie都不存在