展示型网站建设流程图,网站合同建设模板,保定企业网站的建设,建网站用什么系统1.关系型数据库
插件#xff1a;Microsoft.EntityFrameworkCore.InMemory
Microsoft.EntityFrameworkCore.InMemory 是一个用于测试的“临时内存数据库”#xff0c;让你在不连接真实数据库的情况下#xff0c;测试 EF Core 的功能。
使用时就是用具体这个框架里面已经…1.关系型数据库
插件Microsoft.EntityFrameworkCore.InMemory
Microsoft.EntityFrameworkCore.InMemory 是一个用于测试的“临时内存数据库”让你在不连接真实数据库的情况下测试 EF Core 的功能。
使用时就是用具体这个框架里面已经自带的数据库方法去操作这个临时的数据库。
要手动的给这个数据库的设置参数见configDictionary 部分如果 真实的数据库有相关参数的话如图 2. 非关系型数据库
测试方法一[Fact]
前言如果用Xunit 测试框架准备工作配置moq模拟依赖行为FluentAssertions 包 判定测试结果。
比如 MongoDB直接建一个新的 MongoDB。
1. 把测试关联的那些属性方法等变成 virtual 可以后续在 test里面 overwrite。
并且可以 {getset}
2. test unit 里面要去和原项目关联。 project reference)
3. 如果数据有相关的配置 settings必须显性的继承参数属性不然数据库没有办法取到设置参数并且手动设置这写参数的值用 option方法 完整unit 测试截图 AutoMapper依赖隔离说明
注意 在这个项目中BookService使用AutoMapper进行DTO与Entity之间的转换。由于我们Mock了IMapper接口AutoMapper不会执行真实的映射逻辑因此需要手动创建两个测试对象来模拟完整的数据流程
mappedBook - 模拟DTO转Entity后保存到数据库前的状态
Book mappedBook new Book(test, description, 1); // 无ID因为还没存入数据库createdBook - 模拟保存到数据库后的状态
Book createdBook new Book(test, description, 1) { Id 1 }; // 有ID数据库自动生成测试方法二[Theory]
通过 Xunit 测试框架 传递 inline data 到测试方法上设置几个可能会报错的参数组合 注意 _bookService 的调用被延迟了通过 FuncTask 将方法调用包装成委托delegate实现延迟执行等到 func.Should() 调用时才真正触发。
如果直接写 await _bookService.CreateBook(badRequest)方法会立即执行并抛异常测试框架还没来得及准备捕获异常程序就已经崩溃了
总结建真实的数据库使这个测试避免了复杂的配置接口等等直接可以用数据库的context同时只mock 需要的方法或者属性使测试更加简单高效
面试的点
如果面试官问 在项目中有什么挑战解决了哪些问题那咋们可以围绕下面的内容展开说
描述问题背景
我们之前的项目遇到了一个头疼的问题。就是写单元测试特别难受因为我们的代码直接连MongoDB每次跑测试都得连真实的数据库。结果就是测试跑得特别慢一套下来要30秒而且还经常出问题可能上一个测试改了数据下一个测试就挂了特别不稳定。
思考解决方案的过程
我当时就想这样下去不行啊得想个办法。我看了几个方案 用Repository模式吧确实对测试友好但是要改的代码太多了有点担心改出别的bug 试了试InMemory Database但是发现MongoDB的内存版本跟真实环境还是有差别不太放心 后来想到用Virtual Mock的方式改动最小
最后怎么解决的
最后我选了virtual这个方案其实挺简单的 就是把MongoDB Context里面的方法加个virtual关键字然后测试的时候继承一个新的Context类把需要的方法重写一下返回我们准备好的测试数据这样就不用真的去连数据库了。
这个方案最大的好处就是现有的代码基本不用动只是加个关键字的事。
结果
效果还挺明显的 测试速度快了很多从30秒直接降到3秒快了10倍 团队的同事也更愿意写测试了因为跑得快嘛覆盖率从30%升到了70% 而且这个方案比较好理解新同事也容易上手
总结
这件事让我感触挺深的。有时候不一定要用最高大上的方案关键是要适合团队的实际情况。我们的方案可能不是最完美的但是解决了问题而且大家都能接受我觉得这就够了。
