Question

我有以下方法：

User IDataContext.AuthenticateUser(string userName, string password)
{
   byte[] hash = PasswordHasher.HashPassword(userName, password);

   var query =
       from e in mContext.GetTable<User>()
       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)，那么我的单元测试将通过，但是当我与LinqToSql交谈时，我得到一个异常。（System.NotSupportedException：不支持查询运算符'SequenceEqual'。）

有没有办法可以编写这个查询来满足我使用内存模拟的单元测试，以及使用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

这不适合进行单元测试。通过使用.Net的相等性测试SQL的相等性会产生什么价值？

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

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

这三种被叫方法中的每一种都可以进行单元测试。单元测试原始方法有什么意义？

比较LINQ-to-SQL中的byte []和使用mocking的单元测试

2 个答案: