比较LINQ-to-SQL中的byte 和使用mocking的unit testing

我有以下方法：

User IDataContext.AuthenticateUser(string userName, string password) { byte[] hash = PasswordHasher.HashPassword(userName, password); var query = from e in mContext.GetTable() where e.Email == userName && e.Password == hash select e; return query.FirstOrDefault(); } 

当mContext是System.Data.Linq.DataContext一切都很好。 但是，当我的联合测试期间mContext是内存中的模拟时， e.Password和hash之间的比较总是返回false 。

如果我将此比较重写为e.Password.SequenceEqual(hash) ，那么我的unit testing将通过，但是当我与LinqToSql交谈时，我得到一个exception。 （System.NotSupportedException：不支持查询运算符’SequenceEqual’。）

有没有办法可以编写这个查询来满足我的内存模拟unit testing，以及LinqToSql的生产组件？

Answer 1

这是一个有趣的。 我想不出一种方便的方法来拦截平等而不破坏一切，但是：用户名是否是唯一的？ 您可以在LINQ中包含用户名条件，然后检查常规c＃中的哈希值。 在传输数据方面，传递数据并将其取出之间几乎没有区别，特别是如果我们针对成功案例进行优化（在这种情况下，这会降低 IO要求）。

注意：如果执行此操作，则返回“未找到”和“不匹配”的相同结果。

因为byte [] compare不再依赖于LINQ-to-SQL的特殊处理，所以它现在应该可以在你的模拟中正常工作。

 var user = (by name).SingleOrDefault(); if(user==null) #fail bool hashMatch = /* compare array */ if (!hashMatch) #fail return user; 

Answer 2

这不是unit testing的好选择。 通过使用.Net的相等性来测试SQL的相等性会产生什么价值？

在伪代码中，我看到（实质上）三个方法调用：

 HashPassword(); ConstructQuery(); FirstOrDefault(); 

这三种被称为方法的每一种都可以进行unit testing。 unit testing原始方法有什么意义？