当前位置: 首页 > news >正文

淮安网站开发工程师招聘网十大不收费的软件2023年

淮安网站开发工程师招聘网,十大不收费的软件2023年,百度推广网址,电子商务网站建设基础考试测试对于软件来说#xff0c;是保证其质量的一个重要过程#xff0c;而测试又分为很多种#xff0c;单元测试、集成测试、系统测试、压力测试等等#xff0c;不同的测试的测试粒度和测试目标也不同#xff0c;如单元测试关注每一行代码#xff0c;集成测试关注的是多个模…  测试对于软件来说是保证其质量的一个重要过程而测试又分为很多种单元测试、集成测试、系统测试、压力测试等等不同的测试的测试粒度和测试目标也不同如单元测试关注每一行代码集成测试关注的是多个模块是否能正常的协同工作。  当我们在衡量代码好坏时其中一点就是这些代码是否进行了单元测试测试的质量、代码覆盖率怎么样本文将从以下几个方面介绍.Net Core中的单元测试单元测试简介.Net Core中的单元测试框架使用xUnit.Net对.Net Core应用进行单元测试创建xUnit.Net测试项目编写测试方法断言运行单元测试Mock单元测试代码覆盖率小结单元测试简介  单元测试是指对软件中的最小可测试单元进行检查和验证而.Net中最小可测试单元就是类和方法单元测试是白盒测试关注于代码执行逻辑所以单元测试代码一般也由开发人员编写。  单元测试关注的两个重点就是最小可测试单元和代码逻辑但是很多情况下一个类或者是方法它会依赖一些外部组件如其他开发人员写的代码、第三方类库、数据库、网络等当被测试的代码与这些组件紧耦合时那么这段代码将可能是不可测的如一个方法中依赖一个数据库组件去访问数据库那么在执行这个方法时必然要与数据库交互如果没有数据库那么该方法就无法运行。  所以单元测试不仅是对代码逻辑进行检查同时还对整个代码结构有所限制面向对象编程时应当遵循“依赖倒置”原则模块应该依赖抽象抽象不应该依赖实现。并且所依赖的抽象应该显示的通过构造或者方法参数进行暴露让组件的使用者对组件的依赖一目了然。  而在单元测试时为了屏蔽这些抽象依赖不同测试框架中提供了stub、mock、fake等方式对抽象进行模拟以便于代码能够正常执行。.Net Core中的单元测试框架  .Net Core中常用的单元测试的框架有MSTest、NUnit和xUnit.net它们的使用方法都非常相似都是通过特性标记的方式声明测试方法然后在方法中使用断言(Assertions)来判别方法执行结果是否达到预期。  这三个框架中MSTest是与VS集成的而NUnit和xUnit.net都加入了.Net基金会下面两个图分别是三个框架特性和断言的比较(内容来自https://xunit.github.io/docs/comparisons)  特性    断言(部分)     三个框架自有优点但xUnit.net使用更广泛一些(许多开源项目都使用xUnit.net包括ASP.NET Core MVC、EF Core等项目)支持.Net下的大部分平台(.Net Fx、.Net Core、UWP、Xamarin)并且具有非常好的可拓展性。使用xUnit.Net对.Net Core应用进行单元测试  本文使用xUnit.Net框架来对.Net Core程序进行单元测。创建xUnit.Net测试项目  在解决方案中添加.Net Core的被测试项目以及xUnit测试项目    目录结构    xUnit测试项目还提供了相应的代码分析器来帮助编写测试代码  编写测试方法  在被测试的项目中添加一个计算器类型并添加加法运算的方法     在测试项目中添加Calulator方法的测试代码  断言  在程序中断言指的是一个表达式语句执行时总是为真(True)它有助于代码阅读、调试、编译和缺陷检测当断言内表达式执行为True时不会执行任何操作当结果为false时将会输出一些异常信息下图是.Net中System.Diagnositics命名空间下提供的代码调试使用的断言用法(在调试程序时当参数x y就会中断并抛出异常信息)    更多参考https://docs.microsoft.com/en-us/visualstudio/debugger/assertions-in-managed-code  在单元测试中测试方法也是使用断言的方式来判别程序执行结果与预期结果是否相符    xUnit.net中的断言参考https://github.com/xunit/assert.xunit运行单元测试  在VS中可以使用VS的测试窗口运行测试方法    运行结果(测试通过)    运行结果(测试未通过)  Mock  在文章前面提到过面向对象编程应该显示的依赖抽象单元测试时应该将屏蔽依赖的影响(无论是依赖还未实现或者实现的依赖会阻碍代码执行)为了满足这一需求出现了Mock、Fake等方式其原理就是创建一个假的空的依赖并用其替代真实依赖以确保代码能够运行。  .Net中一个常用的Mock框架是Moq本文将使用Moq来介绍如何对依赖进行模拟  1. 编写需要依赖的代码      上面代码中UserManager依赖一个用户的仓储类型该仓储将会与数据库交互。  2. 为测试项目安装Moq组件    3. 编写测试代码    上面代码通过Moq组件Mock了一个IUserRepository的类型并将其Add方法设置并返回true(注设置方法时参数的数据要与调用时使用的一致)最后通过Mock的对象实例Object来创建UserManager实例。  最后断言当创建用户时年龄为负数则抛出FormatException。  4. 运行测试    测试成功。单元测试代码覆盖率  测试代码覆盖率是对单元测试的一种度量可以用来衡量单元测试是否达标一般将代码测试目标定到80%-90%之间为了保证代码覆盖率在写测试用例时就要从语句覆盖、条件覆盖、路径覆盖等方面进行充分考虑。  而.Net Core中如何在测试时计算代码覆盖率呢如果使用VS的企业版那么VS自带了代码覆盖率分析工具     详情参考https://docs.microsoft.com/en-us/visualstudio/test/using-code-coverage-to-determine-how-much-code-is-being-tested       https://github.com/Microsoft/vstest-docs/blob/master/docs/analyze.md#coverage  注VS集成了MSTest所以代码覆盖分析工具对MSTest支持非常好但对xUnit.Net的支持如何笔者未进行测试。  对于xUnit.net来说要分析测试代码覆盖率还可以通过“OpenCover”和“ReportGenerator”工具完成下面就介绍如何通过这两个工具完成代码覆盖率的分析  1. 下载并安装OpenCover在OpenCover的GitHub上下载最新release的zip包并解压缩到指定目录下并将OpenCover目录添加到环境变量中    地址https://github.com/OpenCover/opencover/releases  2. 通过命令行使用OpenCover来完成覆盖率分析  OpenCover有许多参数具体参考https://github.com/OpenCover/opencover/wiki/Usage  在本例中仅需要指定目标程序是dotnet.exe目标程序参数是test(注.Net Core的测试功能实际上是用.Net Core的CLI命令 dotnet test完成的)另外指定输出文件名register参数用于注册代码分析器默认使用user即可-filter参数用于过滤不需要分析覆盖率的程序集和类型-oldstyle是为了支持.Net Core程序添加的参数(详见https://github.com/OpenCover/opencover/issues/595)  另外为了能够满足测试需要在相关项目文件中添加以下节点(详见https://github.com/Microsoft/vstest/issues/800)PropertyGroupDebugTypefull/DebugType/PropertyGroup  最后在项目目录下执行以下命令  OpenCover.Console.exe -target:dotnet.exe -targetargs:test -output:coverage.xml -register:user -filter:[*]* -[*Moq]* -[xunit*]* -oldstyle    生成的结果   4. 通过ReportGenerator生成可读报表  下载地址https://github.com/danielpalme/ReportGenerator/releases  注下载解压后将ReprotGenerator的目录添加到环境变量以便使用。  执行以下命令  ReportGenerator.exe -reports:coverage.xml -targetdir:report    生成内容    打开index.htm文件    5. 在项目中创建一个bat文件用于保存代码覆盖率检测和报表生成命令便于使用  小结  本文主要介绍了如何使用xUnit.net测试框架完成.Net Core程序的单元测试以及通过Moq框架来模拟测试目标的相关依赖避免了其它组件对测试代码的影响。  文章的最后介绍了如何使用开源工具OpenCover和ReportGenerator工具来实现.Net Core单元测试代码覆盖率分析这种方案相对VS企业版自带的工具使用上要麻烦一些但好在工具都是开源的对持续集成也有比较好的支持所以不失为一种好的解决方案。  单元测试仅能保证软件的最小可执行单元是正确的真正的软件是由这些最小可执行单元组成的一个整体单元的正确性无法保证整体的正确性下篇文章将对.Net Core的集成测试进行介绍。本文链接https://www.cnblogs.com/selimsong/p/9263957.html 测试代码https://github.com/yqszt/xUnitTestDemo参考  https://en.wikipedia.org/wiki/Unit_testing  https://docs.microsoft.com/en-us/dotnet/core/testing/  https://github.com/aspnet/Home/wiki/Engineering-guidelines#unit-tests-and-functional-tests  http://asp.net-hacker.rocks/2017/03/31/unit-testing-with-dotnetcore.html  https://stackoverflow.com/questions/261139/nunit-vs-mbunit-vs-mstest-vs-xunit-net  http://blog.ploeh.dk/2010/04/26/WhyImmigratingfromMSTesttoxUnit.net/  https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-test?tabsnetcore21  https://stackoverflow.com/questions/38425936/how-to-measure-code-coverage-in-asp-net-core-projects-in-visual-studio  http://dotnetliberty.com/index.php/2016/02/22/moq-on-net-core/  https://github.com/moq/moq4  https://stackoverflow.com/questions/41384459/opencover-reports-missing-pdbs-when-pdbs-are-present-xunit-net-core  https://github.com/OpenCover/opencover  https://github.com/danielpalme/ReportGenerator相关文章好代码是管出来的——使用Git来管理源代码好代码是管出来的——Git的分支工作流与Pull Request好代码是管出来的——使用GitHub好代码是管出来的——C#的代码规范好代码是管出来的——.Net中的代码规范工具及使用原文地址https://www.cnblogs.com/selimsong/p/9263957.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
http://wiki.neutronadmin.com/news/2064/

相关文章: