LmC*_*LmC 7 c# nhibernate unit-testing mocking fluent-nhibernate
我正在尝试学习如何模拟我的通用存储库,以便我可以对我的所有服务进行单元测试.
我使用NHibernate Fluent来处理数据访问和Ninject的依赖(我对测试不感兴趣)
我的存储库界面如下所示:
public interface IRepository<TEntity> where TEntity : class
{
IQueryable<TEntity> GetAll();
TEntity Get(int key);
void Insert(TEntity entity);
void Update(TEntity entity);
void Delete(int id);
}
Run Code Online (Sandbox Code Playgroud)
实际的存储库看起来像:
public class GenerRepository<TEntity> : IRepository<TEntity>where TEntity : Entity
{
protected ISession Session{get { return NHibernateHelper.OpenSession(); }}
public IQueryable<TEntity> GetAll(){return Session.Query<TEntity>();}
public TEntity Get(int key){return Session.Get<TEntity>(key);}
public void Insert(TEntity entity){Session.Save(entity);}
public void Update(TEntity entity){Session.Update(entity);}
public void Delete(int id){Session.Delete(Session.Load<TEntity>(id));}
}
Run Code Online (Sandbox Code Playgroud)
我的所有服务都执行以下操作,将创建的存储库放入其中并使用它.
我已经阅读了很多关于如何做到这一点的文章,但没有一篇很简单或很好解释.所以在创建测试通用存储库或甚至模拟它之间的任何建议.我也有兴趣创建一个内存数据库但是如何在我的测试项目中为流畅的nhibernate设置配置而不在我的实际项目中编辑代码?
是否可能只是使通用存储库命中一个Tentity列表而不是数据库或内存数据库.
感谢阅读并期待建议.
我的回答应该/可能是评论,也许.因为我想告诉你:不要这样做.不要浪费时间来创建从持久性返回的数据.并且不要把时间花在:从客户端获取数据并将它们放入内存中的某个虚拟DB中.
您需要确保您的服务(使用存储库)可以真正序列化/呈现真实数据.并反序列化/坚持改变.这确实需要真实的数据.
而是花一些时间来创建脚本,这将填充测试数据.您可以在测试中获得的数据:进行业务验证时,服务数据序列化 ......
另外看看这里:Ayende:NHibernate单元测试.提取物:
当使用NHibernate时,我们通常只想测试三件事,即持久化属性,级联按预期工作,查询返回正确的结果.为了做所有这些,我们通常不得不与一个真实的数据库交谈,试图伪造这个级别的任何人是徒劳的,并且会变得非常复杂.
注意:前段时间,我们曾经将所有测试都包装在Transaction Begin()和Rollback().哪个看起来不错.但是我们意识到,很多东西 - 因为缺少Flush()调用 - 没有被完全测试(例如设置not-null).
我不得不同意Radim,这个单元通过在大多数情况下模拟nhibernate功能来测试nhibernate代码,而不是你想做什么.
除非您想测试基于您通过nhibernate检索的数据的复杂业务逻辑,否则这非常好.
但是要测试您的映射,数据检索和持久性是否正常,您必须针对真实数据库进行测试.
如果您的目标是MSSQL Server,我不会使用其他类型的数据库.相反,SQL Express具有真实服务器的所有功能.MSSQL Express可以选择与本地DB一起安装.这将允许您通过连接字符串加载mdf文件,这将或多或少地实例化MSSQL Server的实例...
我用它进行集成测试,效果非常好.
Data Source=(LocalDB)\v11.0;AttachDbFileName=[whateverthepathis]\DatabaseFileName.mdf;InitialCatalog=DatabaseName;Integrated Security=True;MultipleActiveResultSets=True这样你的测试每次都会运行一个空的数据库,你将拥有可重现的集成测试,而不需要真正的服务器,你必须创建一个数据库或每次重置它...
有几种方法可以实现这一点,
使用真实的数据库进行测试,使用脚本来设置和恢复数据库,但使用这种方法,当数据库发生更改时,创建和维护这些脚本需要时间和精力
使用真实的数据库,并使用事务范围进行测试(启动事务持久化,并进行测试,完成后仅回滚事务),这是一个非常好的方法,我将其用于大型项目。然而,一个问题是运行测试需要很多时间(我有大约 3500 个测试,运行它们总共需要 40 分钟)
使用虚假存储库(具有内部实体列表)进行业务逻辑测试,并使用实际存储库来验证映射。这种方法需要额外的努力来创建和维护假存储库。可以在虚假存储库上执行在实际存储库上执行的相同测试,以验证虚假存储库是否正常工作。使用这种方法测试执行会更快。
| 归档时间: |
|
| 查看次数: |
10152 次 |
| 最近记录: |