我有一个服务层,它有一系列方法.这些方法实现了缓存,如下所示：

string key = "GetCategories";
if (CacheHandler.IsCachingEnabled() && !CacheHandler.ContainsKey(key))
{
    var categories = RequestHelper.MakeRequest("get_category_index")["categories"];
    var converted = categories.ToObject<List<Category>>();
    CacheHandler.InsertToCache(key,converted);
    return converted;
}
return CacheHandler.GetCache(key) as List<Category>;

现在,问题是我也想进行单元测试,如下所示：

[TestMethod]
public void GetCategories()
{
    IContentService contentService = new ContentService();
    var resp = contentService.GetCategories();
    Assert.IsNotNull(resp,"Should not be null");
}

问题是,在单元测试期间,我的CacheHandler中的HttpContext.Current是空的(显然).

解决这个问题的最简单方法是什么？

(请尽可能具体,因为我之前没有做过很多单元测试)

这个尖叫 dependency injection.我看到的主要问题是你静态访问CacheHandler,所以在单元测试中,你：
a)在没有“测试”CacheHandler的情况下也无法测试服务
b)不能向服务提供任何其他CacheHandler,例如 mocked

如果在你的情况下这是可能的,我要么重构或至少包装CacheHandler,以便服务访问它的实例.在单元测试中,您可以为服务提供一个“假的”CacheHandler,它不会访问HttpContext,也可以让您对测试本身进行非常精细的控制(例如,您可以测试项目缓存时会发生什么情况.当它不在两个绝对独立的单元测试中)

对于模拟部分,我认为最简单的方法是创建一个接口,然后使用一些专为测试而设计的自动插锁/代理生成框架,例如Rhino Mocks(但还有更多,只是碰巧我正在使用这个并且我非常很高兴:)).另一种方法(初学者更容易,但在实际开发中更麻烦)只是设计CacheHandler(或其包装器),以便您可以继承它并自己覆盖行为.

最后,对于注入本身,我发现了一个方便的“模式”,它利用了C#默认方法参数和标准构造函数注入.服务构造函数看起来像：

public ContentService(ICacheHandler cacheHandler = null)
{
    // Suppose I have a field of type ICacheHandler to store the handler
    _cacheHandler = cacheHandler ?? new CacheHandler(...);
}

所以在应用程序本身,我可以调用没有参数的构造函数(或者让框架构造服务,如果它是ASP.NET处理程序,WCF服务或其他类的类),并且在单元测试中,我可以提供任何实现上述的接口.

对于Rhino Mocks,它看起来像这样：

var mockCacheHandler = MockRepository.GenerateMock<ICacheHandler>();
// Here I can mock/stub methods and properties,set expectations etc...
var sut = new ContentService(mockCacheHandler);

我试图首先使用EntityFramework代码测试我的代码.为了使其可测试并允许隔离测试,我创建了一个我的DbContext实现的接口.我没有测试DbContext类 – 我将假设EF代码按预期工作.

现在,请考虑以下方法：

public IEnumerable<User> GetoddId()
{
    return context_.Users.Where((u,i) => i % 2 == 1).AsEnumerable();
}

这个方法将通过我的模拟FakeDbSet传递(因为它将使用内存中的LINQ提供程序),而在使用EF / LINQ to sql驱动程序时它会因异常而失败.

你会不会留下它并希望人们知道不要写这样的问题？你会放弃隔离测试并测试实际的数据库吗？

具有DataMigrations的LocalDb(可能带有适当的种子)是否有助于对实际数据库进行测试？

请证明答案是正确的.

TLDR：如何测试EntityFramework代码,考虑内存LINQ和sql LINQ之间的差异？

很久以后编辑：我发现了一个非常好的框架,完全符合我的需要.我写了一篇关于unit testing with Effort的博客文章.另外请注意即将到来的EF6可能不需要这些,它承诺了一些单元测试功能.

为此,我们使用sqlite的内存数据库.它们可以非常快速地创建,查询和拆除,并且几乎不会对整体测试速度产生任何影响.一旦您为自己设置了一个测试框架来创建数据库并注入数据,就可以快速编写测试.

当然,sqlite是一个比大多数人简单得多的数据库,因此复杂的查询可能无法转换为其sql版本,但是为了测试90％的情况,它运行良好.

这些测试是否构成集成测试？我不这么认为.它们仍然只测试一个代码单元,即生成LINQ查询的位.您正在测试两件事：1)查询返回正确的数据(但您可以使用内存中的集合检查这一点),以及2)查询可以由Entity Framework转换为有效的sql.测试后者的唯一真正方法是在真实的实体框架中使用存根数据库触发查询.

虽然你可以说真正的单元测试应该只测试你的代码的输出(即解析和检查已生成的表达式树),以及更难写,但它并没有真正证明什么.例如,如果您修改代码以生成内部联接而不是子查询,您是否希望测试中断？只有当它返回不同的结果时,我才会想到.

我正在编写一个客户端,每秒向服务器发送一个“心跳信号”.客户端在后台线程中调用WCF服务以报告其活动.

如何对此进行单元测试？我是否需要等待几秒钟并检查是否多次调用了适当的方法？

它应该是某种情景测试吗？也许我不应该担心在整个客户的整个生命周期中不断调用服务？

我可以测试对WCF服务的单个调用,但它不测试“心跳模式”.

我正在使用TDD方法. (C#,NUnit,Moq)

有什么建议或例子吗？

编辑：

我认为还不够清楚.

这是我所拥有的更简单的版本：

public class FeedService
{
   private Timer t;

   public FeedService()
   {
      t.Interval = 1000;
      t.Elapsed += TimerElapsed;
      t.Start();
   }

   private void TimerElapsed(object sender,ElapsedEventArgs e)
   {
      t.Stop();
      SendHeartbeat();
      t.Start();
   }
}

……这是我的考验：

[Test]
public void Heartbeat_called_twice_after_2_seconds()
{
  var mockFeedService = new Mock<FeedService>();

  Thread.Sleep(2000);
  mockFeedService.Verify(x => x.SendHeartBeat(),Times.AtLeast(2));
}

我有两个问题：
1)为什么我的测试总是失败？我做错了什么？
2)我应该测试一下吗？

必须首先隔离要测试的功能.例如,在这种情况下,可以测试两个方面.一个是listenbeat组件实际上在指定的时间表上发送心跳消息.另一个是服务接收消息.如果您抽象服务,那么您可以独立于服务实现测试听力组件.这可以在单元测试中通过启动听力组件然后休眠,然后验证存根或模拟服务实现接收到预期数量的消息来完成.确保服务正在接收消息的测试是 integration test,因此不是“纯”单元测试.但是,由于必须进行测试,因此您也可以使用测试用例.

我有三个看起来像这样的函数：

private Node GetNode(Node parentNode)
{
    var node = new node();

    switch (parentNode.NodeType)
    {
       case NodeType.Multiple:    node = GetMultipleNode(parentNode)
       case NodeType.Repeating:   node = GetRepeatingNode(parentNode)
    }

    return node;
}

private Node GetMultipleNode(Node parentNode)
{
    foreach (var child in parentNode.Children)
        return GetNode(child);
}

private Node GetRepeatingNode(Node parentNode)
{
    for (int i=0; i < parentNode.Count; i++)
         return GetNode(new Node(i));  // Assume meaningful constructor for Node
}

鉴于这三种方法是相互递归的,那么如何独立地对它们进行单元测试呢？

通常,您不需要单独测试每个方法 – 您可以测试顶级方法是否正确.

但是,如果由于某种原因您希望单独测试每个方法,则可以像测试任何具有依赖项的方法一样使用依赖项注入.这里唯一的区别是依赖是对象本身.以下是一些示例代码来演示这个想法：

class NodeGetter : INodeGetter
{
    public Node GetNode(Node parentNode)
    {
        return GetNode(parentNode,this);
    } 

    public Node GetNode(Node parentNode,INodeGetter nodeGetter)
    {
        switch (parentNode.NodeType)
        {
           case NodeType.Multiple:
               return nodeGetter.GetMultipleNode(parentNode,nodeGetter);
           case NodeType.Repeating:
               return nodeGetter.GetRepeatingNode(parentNode,nodeGetter);
           default:
               throw new NotSupportedException(
                   "Node type not supported: " + parentNode.NodeType);
        }
    }

    public Node GetMultipleNode(Node parentNode,INodeGetter nodeGetter)
    {
        foreach (Node child in parentNode.Children)
        {
            return nodeGetter.GetNode(child);
        }
    }

    public Node GetRepeatingNode(Node parentNode,INodeGetter nodeGetter)
    {
        for (int i = 0; i < parentNode.Count; i++)
        {
            // Assume meaningful constructor for Node
            return nodeGetter.GetNode(new Node(i));
        }
    }
}

测试nodegetter参数时,传递一个mock.

我还将您的方法从私有更改为公共,因为最好只测试您的类的公共接口.