DotNetCore跨平台~为Lind.DotNetCore框架添加单元测试的意义

单元测试大叔认为有几下两个必要的作用,也是为什么要上单元测试的原因

  1. 组件,框架在修改和BUG解决后,进行正确性的测试,然后才能打包
  2. 业务模块,主要提现在进行业务规则的模拟上面,保证了业务逻辑的准确

目前添加了组件正确性的测试,在组件进行升级和优化之后,需要走一篇测试流程,以它的正确!

有条件的同学,可以在自己的源代码管理上添加pipeline,在你的新项目修改迁入后,让它自动进行测试,这样也可以保证项目的质量!

这应该也是TDD开发的初忠吧!

本文转自博客园张占岭(仓储大叔)的博客,原文链接:DotNetCore跨平台~为Lind.DotNetCore框架添加单元测试的意义,如需转载请自行联系原博主。

时间: 2024-07-31 16:40:47

DotNetCore跨平台~为Lind.DotNetCore框架添加单元测试的意义的相关文章

DotNetCore跨平台~文章索引~永久更新

本索引目录主要包括仓储大叔对dotnet core架构的研究与知识积累,从2016年开始进行撰写,到今天已经有一年多了,其中有一些小知识,小技巧,小应用,希望给大家在开发时一些启发,也希望dotnet core越来越好,希望2.0正式版快点出来! 我们的框架应该是基于组件化的! 我们的系统应该是基于微服务化的! 我们的部署,应该是基于自动化的! DotNetCore跨平台目录 DotNetCore跨平台~Startup类的介绍(2016-05-31 16:25) Linux~centos上安装.

DotNetCore跨平台~Moq框架实现模拟测试

当我们进行软件开发时,一般会写单元测试,而对于业务情景来说,一般是测试它的业务逻辑准确性,对于你的测试数据是否来自数据库还是文件,是否为真实还是模拟,并不是很关心!我关心的就是我的业务逻辑是否正确! 所以我们的单元测试在调用底层接口时,尤其是数据持久层的接口时,一般可以使用mock的方式,即模拟一个接口,期望的参数和期望的结果就够了,而没有必要真正去连接数据库,事实上,在业务测试里,使用真实的数据库没有什么意义!无非是加大测试的复杂度! 一个不错的mock测试工具 Moq,它在nuget上已经有

DotNetCore跨平台~聊聊中间件

在进行.net core平台之后,我们如果希望在请求过程中添加一些事件是非常容易的,你可以把这些事件做成一个中间件Middleware,然后这些中间件就会以Http pipeline的管道方式进行相应,并且它们就像是一个职责链,从你定义的第一个中间件开始,一个一个向下传递,直到最后一个中间件完成为止! 前几天我写了在.net core里实现模块化服务,DotNetCore跨平台~组件化时代来了 主要是将我们定义的组件添加到IServiceCollection集合里,然后在程序启动后去注册它们,而

DotNetCore跨平台~功能测试TestHost的使用

之前写了关于自动化测试的相关文章,包括gitlab,unittest,jenkins pipeline等,基于都是功能点的测试,当我们的框架或者业务修改之后,需要走一篇自动化测试,以此来保证我们的修改过的功能是正确的,而今天主要说一下流程测试,从api网站的入口,从一个请求开始到结束这个过程,我们可以通过TestHost来完成! 一个完整的流程化测试需要经过以下几个步骤: 建立xunit项目 引用需要测试的api项目 添加WebFixture拦截器,注意其中的startup是指api项目的,建立

DotNetCore跨平台~一起聊聊Microsoft.Extensions.DependencyInjection

写这篇文章的心情:激动 Microsoft.Extensions.DependencyInjection在github上同样是开源的,它在dotnetcore里被广泛的使用,比起之前的autofac,unity来说,它可以说是个包裹,或者叫适配器,它自己提供了默认的DI实现,同时也支持第三方的IOC容器,在这段时间里使用了它,就想,这东西为什么被在dotnetcore里大放异彩?为什么会全程使用它?从程序的开始到程序启动起来,你可以发现它无处不在,在框架里是这样,在业务层同时也是这样. 聊聊Mi

DotNetCore跨平台~linux上还原自主nuget包需要注意的问题

问题的产生的背景 由于我们使用了jenkins进行部署(jenkins~集群分发功能和职责处理),而对于.net core项目来说又是跨平台的,所以对它的项目拉取,包的还原,项目的编译和项目的发布都是在一台linux的jenkins节点上进行的,而我们开发时是在windows系统,所以在进行还原和编译时出现了一些问题,今天的文章主要是解决这些问题的. .net frameworks时代 我们在.net时代有包管理工具nuget,并且已经知道了它的好处,类似于nodejs的npm,帮助我们管理项目

DotNetCore跨平台~Quartz定时单次任务

之前写过一篇文件<DotNetCore跨平台~Quartz热部署的福音-监控文件夹的变化>,今天主要把框架优化了一下,支持外部触发,并支持外部将参数以JobDataMap形式进行输入,然后在咱们的Job里进行使用它,故称参数化任务. Quartz使用场景: 定时单次任务:在未来某个时间去执行一次 定点任务 :在某个时间去执行,可以是轮询的 周期任务 :按某个时间间隔去轮询执行 今天说的外部触发的任务是指第一种,即在未来某个时间点去执行,并且只执行一次.说一下思路,这种任务某个JobBase的子

DotNetCore跨平台~EFCore连接Mysql的方式

在.net frameworks的ef里连接mysql我们已经测试通过了,而在dotnet core里的efCore上去连接mysql我们需要测试一下,并且在测试过程中出现了一些问题,当然最后也是解决了,下面总结一下,分享给大家! mysql项目的依赖包 数据上下文和连接串 数据仓储 添加模块扩展 业务层注入 业务实现 mysql项目的依赖包 Microsoft.EntityFrameworkCore MySql.Data.EntityFrameworkCore 数据上下文和连接串 对于mysq

DotNetCore跨平台~问题~NETCoreAPP, Version=v1.0&#039; compatible with one of the target runtimes: &#039;win10-x64

新建console项目之后,编译程序出现以下错误: Can not find runtime target for framework '.NETCoreAPP, Version=v1.0' compatible with one of the target runtimes: 'win10-x64, win81-x64, win8-x64, win7-x64'. Possible causes:        The project has not been restored or resto