c# - 对跟踪状态的类进行单元测试

Question

我正在抽象我的一个类的历史跟踪部分，使其看起来像这样:

private readonly Stack<MyObject> _pastHistory = new Stack<MyObject>();

internal virtual Boolean IsAnyHistory { get { return _pastHistory.Any(); } }

internal virtual void AddObjectToHistory(MyObject myObject)
{
  if (myObject == null) throw new ArgumentNullException("myObject");
  _pastHistory.Push(myObject);
}

internal virtual MyObject RemoveLastObject()
{
  if(!IsAnyHistory) throw new InvalidOperationException("There is no previous history.");
  return _pastHistory.Pop();
}

我的问题是我想对 Remove 将返回最后添加的对象进行单元测试。

• AddObjectToHistory
• RemoveObjectToHistory -> 返回通过 AddObjectToHistory
放入的内容

但是，如果我必须先调用 Add，这不是真正的单元测试吗？但是，我能看到以真正的单元测试方式执行此操作的唯一方法是在构造函数中传入 Stack 对象或模拟 IsAnyHistory...但模拟我的 SUT 也很奇怪。所以，我的问题是，从教条的角度来看，这是一个单元测试吗？如果没有，我该如何清理它……构造函数注入(inject)是我唯一的方法吗？必须传递一个简单的对象似乎有点困难？即使是这个简单的对象也可以推出来进行注入(inject)吗？

Answer 1

这些场景有两种方法:

1. 干预设计，例如制作 _pastHistory internal/protected 或注入(inject)堆栈
2. 使用其他(可能经过单元测试的)方法进行验证

一如既往，没有黄金法则，尽管我会说您通常应该避免单元测试强制设计更改的情况(因为这些更改很可能会给代码使用者带来歧义/不必要的问题)。

尽管如此，最终还是您必须权衡您希望单元测试代码在多大程度上干扰设计(第一种情况)或弯曲完美单元测试定义(第二种情况)。

通常，我发现第二种情况更有吸引力 - 它不会混淆原始类代码，而且你很可能已经测试过 Add - it's safe to rely on it .