您如何验证您的跨平台.NETCore应用程序在部署到任何地方时都能正常工作？随着业务、团队和技术环境的发展，您的代码能够随之发展吗？通过遵循测试驱动开发的原则，您可以简化代码库，使查找和修复错误变得微不足道，并确保您的代码能够按照您的想法运行。
本书指导开发人员通过建立专业的测试驱动开发流程来创建健壮、可投入生产的C#7和.NETCore应用程序。为此，您将首先学习TDD生命周期的各个阶段、一些最佳实践和一些反模式。
在第一章介绍了TDD的基础知识后，您将立即开始创建一个示例ASP.NETCoreMVC应用程序。您将学习如何使用SOLID原则编写可测试的代码，并设置依赖注入。
接下来，您将学习如何使用xUnit.net测试框架创建单元测试，以及如何使用其属性和断言。一旦掌握了基础知识，您将学习如何创建数据驱动的单元测试以及如何在代码中模拟依赖关系。
在本书的最后，您将通过使用GitHub、TeamCity、VSTS和Cake来创建一个健康的持续集成流程。最后，您将修改持续集成构建，以测试、版本化和打包一个示例应用程序。
本书适用于希望通过实施测试驱动开发原则构建质量、灵活、易于维护和高效企业应用程序的.NET开发人员。
第一章，“探索测试驱动开发”，向您介绍了如何通过学习和遵循测试驱动开发的成熟原则来改善编码习惯和代码。
第二章，“使用.NETCore入门”，向您介绍了.NETCore和C#7的超酷新跨平台功能。我们将通过实际操作来学习，在UbuntuLinux上使用测试驱动开发原则创建一个ASP.NETMVC应用程序。
第三章，“编写可测试的代码”，演示了为了获得测试驱动开发周期的好处，您必须编写可测试的代码。在本章中，我们将讨论创建可测试代码的SOLID原则，并学习如何为依赖注入设置我们的.NETCore应用程序。
第四章，“.NETCore单元测试”，介绍了.NETCore和C#可用的单元测试框架。我们将使用xUnit框架创建一个共享的测试上下文，包括设置和清除代码。您还将了解如何创建基本的单元测试，并使用xUnit断言来证明单元测试的结果。
第五章，“数据驱动的单元测试”，介绍了允许您通过一系列数据输入来测试代码的概念，可以是内联的，也可以来自数据源。在本章中，我们将创建xUnit中的数据驱动单元测试或理论。
第六章，“模拟依赖关系”，解释了模拟对象是模仿真实对象行为的模拟对象。在本章中，您将学习如何使用Moq框架，使用Moq创建的模拟对象来隔离您正在测试的类与其依赖关系。
第七章，持续集成和项目托管，侧重于测试驱动开发周期的目标，即快速提供有关代码质量的反馈。持续集成流程将这种反馈周期延伸到发现代码集成问题。在本章中，您将开始创建一个持续集成流程，该流程可以为开发团队提供有关代码质量和集成问题的快速反馈。
第八章，创建持续集成构建流程，解释了一个出色的持续集成流程将许多不同的步骤整合成一个易于重复的流程。在本章中，您将配置TeamCity和VSTS使用跨平台构建自动化系统Cake来清理、构建、恢复软件包依赖关系并测试您的解决方案。
第九章，测试和打包应用程序，教您修改Cake构建脚本以运行xUnit测试套件。您将通过为.NETCore支持的各种平台版本化和打包应用程序来完成该过程。
假定您具有C#编程和MicrosoftVisualStudio的工作知识。
您可以按照以下步骤下载代码文件：
文件下载后，请确保使用最新版本的解压缩或提取文件夹：
本书中使用了许多文本约定。
CodeInText：表示文本中的代码词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟URL、用户输入和Twitter句柄。这是一个例子：“为了使测试通过，您必须迭代实现生产代码。当实现以下IsServerOnline方法时，预计Test_IsServerOnline_ShouldReturnTrue测试方法将通过。”
代码块设置如下：
[Fact]publicvoidTest_IsServerOnline_ShouldReturnTrue(){boolisOnline=IsServerOnline();Assert.True(isOnline);}任何命令行输入或输出都是按照以下格式编写的：
sudoapt-getupdatesudoapt-getinstalldotnet-sdk-2.0.0粗体：表示新术语、重要单词或屏幕上看到的单词。例如，菜单或对话框中的单词会以这种方式出现在文本中。这是一个例子：“VisualStudioCode将尝试下载Linux平台所需的依赖项，Linux的Omnisharp和.NETCore调试器。”
警告或重要说明看起来像这样。
技巧和窍门看起来像这样。
当开发人员使用开发方法、编码风格和实践来构建代码库时，这些方法会自动使源代码变得僵化且难以维护，软件项目的质量会迅速下降。本章指出了导致编写糟糕代码的习惯和实践，因此应该避免。解释了应该学习的编程习惯、开发风格和方法，以便编写清洁和可维护的代码。
在本章中，我们将涵盖以下主题：
有两种类型的代码——好的代码和糟糕的代码。这两种类型的代码在编译时语法可能是正确的，运行代码可以得到预期的结果。然而，由于编写方式的原因，糟糕的代码在扩展或甚至对代码进行小改动时会导致严重问题。
当程序员使用不专业的方法和风格编写代码时，通常会导致糟糕的代码。此外，使用难以阅读的编码风格或格式，以及未能正确有效地测试代码都是糟糕代码的先兆。当程序员为了满足即将到来的截止日期和项目里程碑而牺牲专业精神时，代码可能会写得很糟糕。
我曾遇到一些软件项目，它们迅速成为被遗弃的遗留软件项目，因为不断出现的生产错误和无法轻松地满足用户的变更请求。这是因为这些软件应用程序在投入生产时积累了严重的技术债务，这是由于软件开发人员编写了糟糕的代码，导致了糟糕的设计和开发决策，并使用了已知会导致未来维护问题的编程风格。
源代码元素——方法、类、注释和其他工件——应该易于阅读、理解、调试、重构和扩展，如果需要由原始开发人员以外的其他开发人员进行；否则，糟糕的代码已经被编写。
当你在扩展或添加新功能时，你会知道你的代码有问题，因为你会破坏现有的工作功能。当代码部分无法解码或对其进行任何更改会使系统停止时，也会发生这种情况。糟糕的代码通常是因为不遵守面向对象和“不要重复自己”（DRY）原则或错误使用这些原则。
DRY是编程中的一个重要原则，旨在将系统分解为小组件。这些组件可以轻松管理、维护和重复使用，以避免编写重复的代码并使代码的不同部分执行相同的功能。
糟糕的代码不仅仅出现在代码库中；程序员写了糟糕的代码。大多数情况下，糟糕的代码可能是由于以下任何原因之一而写成的：
以下代码片段显示了与第三方smpp库紧密耦合的示例：
publicvoidSendSMS(){SmppManagersmppManager=newSmppManager();smppManager.SendMessage("0802312345","Hello","John");}publicclassSmppManager{privatestringsourceAddress;privateSmppClientsmppClient;publicSmppManager(){smppClient=newSmppClient();smppClient.Start();}publicvoidSendMessage(stringrecipient,stringmessage,stringsenderName){//sendmessageusingreferencedlibrary}}代码异味代码异味是由KentBeck首次使用的一个术语，它指出了源代码中的更深层次的问题。代码库中的代码异味可能来自于源代码中的复制、使用不一致或模糊的命名约定和编码风格、创建具有长参数列表的方法以及具有庞大方法和类，即知道并做太多事情，从而违反了单一责任原则。列表还在继续。
在源代码中常见的代码异味是当开发人员创建两个或更多执行相同操作的方法，几乎没有变化或在应该在单个点中实现的程序细节或事实在多个方法或类中复制，导致代码库难以维护。
以下两个ASP.NETMVC动作方法有代码行，创建了一个强类型的字符串年份和月份列表。这些代码行本来可以被重构为第三个方法，并被这两个方法调用，但却在这两个方法中被复制：
[HttpGet]publicActionResultGetAllTransactions(){List
publicvoidProcessTransaction(stringusername,stringpassword,floattransactionAmount,stringtransactionType,DateTimetime,boolcanProcess,boolretryOnfailure){//Dosomething}坏或破损的设计在实施应用程序时，经常会出现结构或设计和模式导致糟糕的代码，尤其是在错误使用面向对象编程原则或设计模式时。一个常见的反模式是意大利面条式编码。这在对面向对象理解不深的开发人员中很常见，这涉及创建具有不清晰结构、几乎没有可重用性以及对象和组件之间没有关系的代码库。这导致应用程序难以维护和扩展。
在经验不足的开发人员中有一种常见的做法，即在解决应用程序复杂性时不必要或不适当地使用设计模式。当错误使用设计模式时，会给代码库带来糟糕的结构和设计。使用设计模式应该简化复杂性，并为软件问题创建可读和可维护的解决方案。当某个模式导致可读性问题并明显增加了程序的复杂性时，值得重新考虑是否使用该模式，因为该模式被误用了。
例如，单例模式用于创建对资源的单个实例。单例类的设计应该有一个私有构造函数，没有参数，一个静态变量引用资源的单个实例，以及一个管理的公共手段来引用静态变量。单例模式可以简化对单一共享资源的访问，但如果没有考虑线程安全性，也可能会导致很多问题。两个或更多线程可以同时访问if(smtpGateway==null)这一行，如果这行被评估为true，就会创建资源的多个实例，就像下面代码中所示的实现一样：
publicclassSMTPGateway{privatestaticSMTPGatewaysmtpGateway=null;privateSMTPGateway(){}publicstaticSMTPGatewaySMTPGatewayObject{get{if(smtpGateway==null){smtpGateway=newSMTPGateway();}returnsmtpGateway;}}}命名程序元素有意义和描述性的元素命名可以极大地提高源代码的可读性。它可以让程序的逻辑流程更容易理解。令人惊讶的是，软件开发人员仍然会给程序元素起太短或者不够描述性的名字，比如给变量起一个字母的名字，或者使用缩写来命名变量。
对元素使用通用或模糊的名称会导致歧义。例如，将一个方法命名为Extract()或Calculate()，乍一看会导致主观解释。对变量使用模糊的名称也是如此。例如：
intx2;stringxxya;虽然程序元素的命名本身就是一门艺术，但是名称应该被选择来定义目的，并简要描述元素，并确保所选名称符合所使用的编程语言的标准和规则。
以下代码片段将执行其预期的功能，尽管其中包含使用糟糕的命名约定编写的元素，这影响了代码的可读性：
publicvoidupdatetableloginentries(){com.Connection=conn;SqlParameterpar1=newSqlParameter();par1.ParameterName="@username";par1.Value=main.username;com.Parameters.Add(par1);SqlParameterpar2=newSqlParameter();par2.ParameterName="@date";par2.Value=main.date;com.Parameters.Add(par2);SqlParameterpar3=newSqlParameter();par3.ParameterName="@logintime";par3.Value=main.logintime;com.Parameters.Add(par3);SqlParameterpar4=newSqlParameter();par4.ParameterName="@logouttime";par4.Value=DateTime.Now.ToShortTimeString();;com.Parameters.Add(par4);com.CommandType=CommandType.Text;com.CommandText="updateloginentriessetlogouttime=@logouttimewhereusername=@usernameanddate=@dateandlogintime=@logintime";openconn();com.ExecuteNonQuery();closeconn();}糟糕的源代码文档当使用编程语言的编码风格和约定编写代码时，可以很容易地理解代码，同时避免之前讨论过的糟糕的代码陷阱。然而，源代码文档非常有价值，在软件项目中的重要性不可低估。对类和方法进行简要而有意义的文档编写可以让开发人员快速了解它们的内部结构和操作。
发布未经充分测试的应用程序可能会产生灾难性后果和维护问题。值得注意的是美国国家航空航天局于1998年12月11日发射的火星气候轨道飞行器在接近火星时失败，原因是由于转换错误导致的软件错误，其中轨道飞行器的程序代码在计算时使用的是磅而不是牛顿。对负责计算度量标准的特定模块进行简单的单元测试可能会检测到错误并可能防止失败。
此外，根据2016年测试优先方法的现状报告，由名为QASymphony的测试服务公司对来自15个不同国家的200多家软件组织的测试优先方法的采用进行了调查，结果显示近一半的受访者在他们开发的应用程序中没有实施测试优先方法。
编写干净的代码需要有意识地保持专业精神，并在软件开发过程的各个阶段遵循最佳行业标准。从软件项目开发的一开始就应该避免糟糕的代码，因为通过糟糕的代码积累的坏账可能会减慢软件项目的完成速度，并在软件部署到生产环境后造成未来问题。
要避免糟糕的代码，你必须懒惰，因为一般说来懒惰的程序员是最好的和最聪明的程序员，因为他们讨厌重复的任务，比如不得不回去修复本可以避免的问题。尽量使用避免编写糟糕代码的编程风格和方法，以避免不得不重写代码以修复可避免的问题、错误或支付技术债务。
//ThedependencyinjectionwouldbedoneusingNinjectpublicISmppManagersmppManager{get;privateset;}publicvoidSendSMS(){smppManager.SendMessage("0802312345","Hello","John");}publicclassSmppManager{privatestringsourceAddress;privateSmppClientsmppClient;publicSmppManager(){smppClient=newSmppClient();smppClient.Start();}publicvoidSendMessage(stringrecipient,stringmessage,stringsenderName){//sendmessageusingreferencedlibrary}}publicinterfaceISmppManager{voidSendMessage(stringrecipient,stringmessage,stringsenderName);}声音架构和设计通过使用良好的开发架构和设计策略可以避免糟糕的代码。这将确保开发团队和组织具有高级架构、策略、实践、准则和治理计划，团队成员必须遵循以防止走捷径和避免在整个开发过程中出现糟糕的代码。
[HttpGet]publicActionResultGetAllTransactions(){varyearsAndMonths=GetYearsAndMonths();ViewBag.Transactions=GetTransactions(yearsAndMonths.Item1,yearsAndMonths.Item2);returnView();}[HttpGet]publicActionResultSearchTransactions(){varyearsAndMonths=GetYearsAndMonths();ViewBag.Years=yearsAndMonths.Item1;ViewBag.Months=yearsAndMonths.Item2;returnView();}private(List
publicvoidProcessTransaction(Transactiontransaction){//Dosomething}publicclassTransaction{publicstringUsername{get;set;}publicstringPassword{get;set;}publicfloatTransactionAmount{get;set;}publicstringTransactionType{get;set;}publicDateTimeTime{get;set;}publicboolCanProcess{get;set;}publicboolRetryOnfailure{get;set;}}开发团队应该有由团队成员共同制定的准则、原则和编码约定和标准，并应不断更新和完善。有效使用这些将防止软件代码库中的代码异味，并允许团队成员轻松识别潜在的糟糕代码。
遵循C#编码约定指南有助于掌握编写清晰、可读、易于修改和易于维护的代码。使用描述性的变量名称，代表它们的用途，如下面的代码所示：
您应该始终尝试编写自解释的代码。这可以通过良好的编程风格实现。以这样一种方式编写代码，使得您的类、方法和其他对象都是自解释的。新的开发人员应该能够使用您的代码，而不必在理解代码及其内部结构之前感到紧张。
编码元素应该具有描述性和意义，以向读者提供洞察力。在必须记录方法或类以提供进一步澄清的情况下，采用“保持简单”的方法，简要说明某个决定的原因。检查以下代码片段；没有人希望为包含200行代码的类阅读两页文档：
//////ThisclassusesSHA1algorithmforencryptionwithrandomlygeneratedsaltforuniqueness///publicclassAESEncryptor{//Codegoeshere}KISS，也称为“保持简单，愚蠢”，是一种设计原则，它指出大多数系统在保持简单而不是使其不必要地复杂时运行得最好。该原则旨在帮助程序员尽可能简化代码，以确保未来可以轻松维护代码。
为了避免由于用户需求变化而对系统进行修改时可能导致的未来问题，以及由于代码库中固有的糟糕代码和累积的技术债务而暴露的错误，您需要具有以未来为考量并接受变化的思维方式。
使用灵活的模式，并且在编写代码时始终遵循良好的面向对象开发和设计原则。大多数软件项目的需求在其生命周期内都会发生变化。假设某个组件或部分不会发生变化是错误的，因此请尝试建立一个机制，使应用程序能够优雅地接受未来的变化。
测试驱动开发（TDD）是一种迭代的敏捷开发技术，强调先测试开发，这意味着在编写生产就绪的代码之前编写测试。TDD技术侧重于通过不断重构代码来确保代码通过先前编写的测试，从而编写干净和高质量的代码。
TDD作为一种先测试的开发方法，更加强调构建经过充分测试的软件应用程序。这使开发人员能够根据在经过深思熟虑后定义的测试任务来编写代码。在TDD中，常见的做法是在编写实际应用程序代码之前编写测试代码。
TDD引入了一个全新的开发范式，并改变了你的思维方式，开始在甚至开始编写代码之前考虑测试你的代码。这与传统的开发技术相反，传统技术将代码测试推迟到开发周期的后期阶段，这种方法被称为最后测试开发（TLD）。
你可能会想，就像每个新接触TDD的开发人员一样，为什么要先写测试，因为你相信自己的编码直觉可以编写始终有效的干净代码，并且通常在编码完成后会测试整个代码。你的编码直觉可能是正确的，也可能不是。在代码通过一组书面测试用例并通过验证之前，没有办法验证这个假设；信任是好的，但控制更好。
TDD中的测试用例是通过用户故事或正在开发的软件应用程序的用例来准备的。然后编写代码并进行迭代重构，直到测试通过。例如，编写用于验证信用卡长度的方法可能包含用例来验证正确长度、不正确长度，甚至当空或空信用卡作为参数传递给方法时。
自TDD最初被推广以来，已经提出了许多变体。其中一种是行为驱动开发（BDD）或验收测试驱动开发（ATDD），它遵循TDD的所有原则，而测试是基于预期的用户指定行为。
关于TDD实践是何时引入计算机编程或者是哪家公司首先使用的，实际上没有任何书面证据。然而，1957年D.D.McCracken的《数字计算机编程》中有一段摘录，表明TDD的概念并不新鲜，早期的人们已经使用过，尽管名称显然不同。
在编码开始之前，可能会对结账问题进行第一次攻击。为了充分确定答案的准确性，有必要准备一个手工计算的检查案例，以便将来与机器计算的答案进行比较。这意味着存储程序机永远不会用于真正的一次性问题。总是必须有迭代的元素来使其付出。
此外，在1960年代初，IBM的人们为NASA运行了一个项目（ProjectMecury），他们利用了类似TDD的技术，进行了半天的迭代，并且开发团队对所做的更改进行了审查。这是一个手动过程，无法与我们今天拥有的自动化测试相比。
TDD最初是由KentBeck推广的。他将其归因于他在一本古老书中读到的一段摘录，其中TDD被描述为简单的陈述，你拿输入磁带，手动输入你期望的输出磁带，然后编程直到实际输出磁带与期望输出相匹配。当他在Smalltalk开发了第一个xUnit测试框架时，KentBeck重新定义了TDD的概念。
可以肯定地说，Smalltalk社区在TDD变得普遍之前就已经使用了TDD，因为社区中使用了SUnit。直到KentBeck和其他爱好者将SUnit移植到JUnit之后，TDD才变得广为人知。从那时起，不同的测试框架已经被开发出来。一个流行的工具是xUnit，可以为大量编程语言提供端口。
此外，一些开发人员抱怨模拟可能会使TDD变得非常困难和令人沮丧，因为所需的依赖关系不应该在实现依赖代码的同时实现，而应该进行模拟。使用传统的测试最后的方法，可以实现依赖关系，然后可以测试代码的所有不同部分。
另一个常见的误解是，在真正意义上，直到确定设计依赖于代码实现之前，测试才不能被编写。这是不正确的，因为采用TDD将确保对代码实现的计划清晰明了，从而产生一个适当的设计，可以帮助编写高效可靠的测试。
有时候，一些人会将TDD和单元测试混为一谈，认为它们是一样的。TDD和单元测试并不相同。单元测试涉及在最小的编码单元或级别上实践TDD，这是一种方法或函数，而TDD是一种技术和设计方法，包括单元测试、集成测试以及验收测试。
刚接触TDD的开发人员经常认为在编写实际代码之前必须完全编写测试。事实恰恰相反，因为TDD是一种迭代技术。TDD倾向于探索性过程，你编写测试并编写足够的代码。如果失败，就重构代码直到通过，然后可以继续实现应用程序的下一个功能。
TDD并不是一个可以自动修复所有糟糕编码行为的灵丹妙药。你可以实践TDD，但仍然编写糟糕的代码甚至糟糕的测试。如果没有正确使用TDD原则和实践，或者试图在不适合使用TDD的地方使用TDD，这是可能的。
TDD，如果正确和适当地完成，可以带来良好的投资回报，因为它有助于开发自测代码，从而产生具有更少或没有错误的健壮软件应用程序。这是因为大部分可能出现在生产中的错误和问题在开发阶段已经被捕捉和修复了。
除了源代码文档，编写测试也是一种良好的编码实践，因为它们作为源代码的微型文档，可以快速理解代码的工作原理。测试将显示预期的输入以及预期的输出或结果。从测试中可以轻松理解应用程序的结构，因为所有对象都将有测试，以及对象方法的测试，显示它们的使用方式。
正确和持续地实践TDD有助于编写具有良好抽象、灵活设计和架构的优雅代码。这是因为，为了有效地测试应用程序的所有部分，各种依赖关系需要被分解成可以独立测试的组件，并在集成后进行测试。
代码的清晰性在于使用最佳行业标准编写代码，易于维护，可读性强，并且编写了用于验证其一致行为的测试。这表明没有测试的代码是糟糕的代码，因为没有直接验证其完整性的特定方式。
测试软件项目可以采用不同的形式，通常由开发人员和测试分析员或专家进行。测试是为了确定软件是否符合其指定的期望，如果可能的话，识别错误，并验证软件是否可用。大多数程序员通常认为测试和调试是一样的。调试是为了诊断软件中的错误和问题，并采取可能的纠正措施。
这是测试的一个级别，涉及测试构成软件应用程序组件的每个单元。这是测试的最低级别，它在方法或函数级别进行。它主要由程序员完成，特别是为了显示代码的正确性和要求是否已经正确实现。单元测试通常具有一个或多个输入和输出。
这是通常在软件开发中进行的第一级测试，旨在隔离软件系统的单元并独立或隔离地测试它们。通过单元测试，系统中固有的问题和错误可以在开发过程的早期轻松检测到。
集成测试是通过组合和测试不同的单元或组件来完成的，这些单元或组件必须在隔离状态下进行测试。这个测试是为了确保应用程序的不同单元可以共同工作以满足用户的需求。通过集成测试，您可以在不同组件交互和交换数据时发现系统中的错误。
这项测试可以由程序员、软件测试人员或质量保证分析员进行。可以使用不同的方法进行集成测试：
这个测试级别是您验证整个集成系统以确保其符合指定的用户需求。这个测试通常在集成测试之后立即进行，由专门的测试人员或质量保证分析员进行。
整个软件系统套件是从用户的角度进行测试，以识别隐藏的问题或错误和可用性问题。对实施的系统进行了严格的测试，使用系统应处理的真实输入，并验证输出是否符合预期数据。
用户验收测试通常用于指定软件应用程序的工作方式。这些测试是为业务用户和程序员编写的，用于确定系统是否符合期望和用户特定要求，以及系统是否根据规格完全和正确地开发。这项测试由最终用户与系统开发人员合作进行，以确定是否正式接受系统或进行调整或修改。
TDD的实践有助于设计清晰的代码，并作为大型代码库中回归的缓冲。它允许开发人员轻松确定新实施的功能是否通过运行测试时获得的即时反馈破坏了先前正常工作的其他功能。TDD的工作原理如下图所示：
这是技术的初始步骤，您必须编写描述要开发的组件或功能的测试。组件可以是用户界面、业务规则或逻辑、数据持久性例程，或实现特定用户需求的方法。测试需要简洁，并应包含组件测试所需的数据输入和期望的预期结果。
在编写测试时，从技术上讲，你已经解决了一半的开发任务，因为通过编写测试来构思代码的设计。在编写的测试之后，更容易处理困难的代码，这就是已经编写的测试。在这一点上，作为TDD新手，不要期望测试是100%完美或具有完整的代码覆盖率，但通过持续的练习和充分的重构，这是可以实现的。
在编写完测试之后，你应该编写足够的代码来实现之前编写的测试所需的功能。请记住，这里的目标是尽量采用良好的实践和标准来编写代码，以使测试通过。应避免所有导致编写糟糕或糟糕代码的方法。
尽量避免测试过度拟合，即为了使测试通过而编写代码的情况。相反，你应该编写代码来实现功能或用户需求，以确保覆盖功能的每种可能用例，避免代码在测试用例执行和生产环境中执行时具有不同的行为。
当你确信已经有足够的代码使测试通过时，你应该运行测试，使用你选择的测试套件。此时，测试可能会通过或失败。这取决于你如何编写代码。
TDD的一个基本规则是多次运行测试，直到测试通过。最初，在代码完全实现之前运行测试时，测试将失败，这是预期的行为。
为了实现完整的代码覆盖率，测试和源代码都必须进行重构和多次测试，以确保编写出健壮且干净的代码。重构应该是迭代的，直到实现完整的覆盖率。重构步骤应该删除代码中的重复部分，并尝试修复任何代码异味的迹象。
TDD的本质是编写干净的代码，从而构建可靠的应用程序，这取决于所编写的测试类型（单元测试、验收测试或集成测试）。重构可以局部地影响一个方法，也可以影响多个类。例如，在重构一个接口或一个类中的多个方法时，建议您逐渐进行更改，一次一个测试，直到所有测试及其实现代码都被重构。
部分采用该技术也可能减少TDD的全部好处。在团队中只有少数开发人员使用该技术而其他人不使用的情况下，这将导致代码片段化，其中一部分代码经过测试，另一部分没有经过测试，从而导致应用程序不可靠。
应避免为自然微不足道或不需要的代码编写测试；例如，为对象访问器编写测试。测试应该经常运行，特别是通过测试运行器、构建工具或持续集成工具。不经常运行测试可能导致情况，即即使已经进行了更改并且组件可能失败，代码基地的真实状态也不为人所知。
TDD技术遵循一个被称为红-绿-重构循环的原则，红色状态是初始状态，表示TDD循环的开始。在红色状态下，测试刚刚被编写，并且在运行时将失败。
下一个状态是绿色状态，它显示在实际应用代码编写后测试已通过。重构代码是确保代码完整性和健壮性的重要步骤。重构将反复进行，直到代码满足性能和需求期望为止。
在周期开始时，尚未编写用于运行测试的生产代码，因此预计测试将失败。例如，在以下代码片段中，IsServerOnline方法尚未实现，当运行Test_IsServerOnline_ShouldReturnTrue单元测试方法时，它应该失败。
publicboolIsServerOnline(){returnfalse;}[Fact]publicvoidTest_IsServerOnline_ShouldReturnTrue(){boolisOnline=IsServerOnline();Assert.True(isOnline);}为了使测试通过，您必须迭代实现生产代码。当实现以下IsServerOnline方法时，预期Test_IsServerOnline_ShouldReturnTrue测试方法将通过。
publicboolIsServerOnline(){stringaddress="localhost";intport=8034;SmppManagersmppManager=newSmppManager(address,port);boolisOnline=smppManager.TestConnection();returnisOnline;}[Fact]publicvoidTest_IsServerOnline_ShouldReturnTrue(){boolisOnline=IsServerOnline();Assert.True(isOnline);}当测试运行并通过时，根据您使用的测试运行器显示绿色，这会立即向您提供有关代码状态的反馈。这让您对代码的正确运行和预期行为感到自信和内心的喜悦。
重构是一个迭代的努力，您将不断修改先前编写的代码以通过测试，直到它达到了生产就绪状态，并且完全实现了需求，并且适用于所有可能的用例和场景。
通过本章讨论的原则和编码模式，可以避免大多数潜在的软件项目维护瓶颈。成为专业人士需要保持一致性，要有纪律性，并坚持良好的编码习惯、实践，并对TDD持有专业态度。
编写易于维护的清晰代码将在长期内得到回报，因为将需要更少的工作量来进行用户请求的更改，并且当应用程序始终可供使用且几乎没有错误时，用户将感到满意。
在下一章中，我们将探索.NETCore框架及其能力和局限性。此外，我们将在审查C#编程语言的第7版中介绍的新功能之前，先了解MicrosoftVisualStudioCode。
当微软发布第一个版本的.NETFramework时，这是一个创建、运行和部署服务和应用程序的平台，它改变了游戏规则，是微软开发社区的一场革命。使用初始版本的框架开发了几个尖端应用程序，然后发布了几个版本。
多年来，.NETFramework得到了蓬勃发展和成熟，支持多种编程语言，并包含了多个功能，使得在该平台上编程变得简单而有价值。但是，尽管框架非常强大和吸引人，但限制了开发和部署应用程序只能在微软操作系统变体上进行。
为了为开发人员解决.NETFramework的限制，创建一个面向云的、跨平台的.NETFramework实现，微软开始使用.NETFramework开发.NETCore平台。随着2016年版本1.0的推出，.NET平台的应用程序开发进入了一个新的维度，因为.NET开发人员现在可以轻松地构建在Windows、Linux、macOS和云、嵌入式和物联网设备上运行的应用程序。.NETCore与.NETFramework、Xamarin和Mono兼容，通过.NET标准。
本章将介绍.NETCore和C#7的超酷新跨平台功能。我们将在UbuntuLinux上使用TDD创建一个ASP.NETMVC应用程序来学习。在本章中，我们将涵盖以下主题：
.NETCore是一个跨平台的开源开发框架，可以在Windows、Linux和macOS上运行，并支持x86、x64和ARM架构。.NETCore是从.NETFramework分叉出来的，从技术上讲，它是后者的一个子集，尽管是简化的、模块化的。.NETCore是一个开发平台，可以让您在开发和部署应用程序时拥有很大的灵活性。新平台使您摆脱了通常在应用程序部署过程中遇到的麻烦。因此，您不必担心在部署服务器上管理应用程序运行时的版本。
目前，版本2.0.7中，.NETCore包括具有出色性能和许多功能的.NET运行时。微软声称这是最快的.NET平台版本。它有更多的API和更多的项目模板，比如用于在.NETCore上运行的ReactJS和AngularJS应用程序的模板。此外，版本2.0.7还有一组命令行工具，使您能够在不同平台上轻松构建和运行命令行应用程序，以及简化的打包和对Macintosh上的VisualStudio的支持。.NETCore的一个重要副产品是跨平台模块化Web框架ASP.NETCore，它是ASP.NET的全面重新设计，并在.NETCore上运行。
.NETFramework非常强大，并包含多个库用于应用程序开发。然而，一些框架的组件和库可能与Windows操作系统耦合。例如，System.Drawing库依赖于WindowsGDI，这就是为什么.NETFramework不能被认为是跨平台的，尽管它有不同的实现。
为了使.NETCore真正跨平台，像WindowsForms和WindowsPresentationFoundation（WPF）这样对Windows操作系统有很强依赖的组件已经从平台中移除。ASP.NETWebForms和WindowsCommunicationFoundation（WCF）也已被移除，并用ASP.NETCoreMVC和ASP.NETCoreWebAPI替代。此外，EntityFramework（EF）已经被简化，使其跨平台，并命名为EntityFrameworkCore。
此外，由于.NETFramework对Windows操作系统的依赖，微软无法开放源代码。然而，.NETCore是完全开源的，托管在GitHub上，并拥有一个不断努力开发新功能和扩展平台范围的蓬勃发展的开发者社区。
.NET标准是微软维护的一组规范和标准，所有.NET平台都必须遵循和实现。它正式规定了所有.NET平台变体都应该实现的API。目前.NET平台上有三个开发平台—.NETCore、.NETFramework和Xamarin。.NET平台需要提供统一性和一致性，使得在这三个.NET平台变体上更容易共享代码和重用库。
.NET平台提供了一组统一的基类库API的定义，所有.NET平台都必须实现，以便开发人员可以轻松地在.NET平台上开发应用程序和可重用库。目前的版本是2.0.7，.NET标准提供了新的API，这些API在.NETCore1.0中没有实现，但现在在2.0版本中已经实现。超过20,000个API已经添加到运行时组件中。
此外，.NET标准是一个目标框架，这意味着你可以开发你的应用程序以针对特定版本的.NET标准，使得应用程序可以在实现该标准的任何.NET平台上运行，并且你可以轻松地在不同的.NET平台之间共享代码、库和二进制文件。当构建应用程序以针对.NET标准时，你应该知道较高版本的.NET标准有更多可用的API，但并不是许多平台都实现了。建议你始终针对较低版本的标准，这将保证它被许多平台实现：
.NETCore作为通用应用程序开发平台，由CoreCLR、CoreFX、SDK和CLI工具、应用程序主机和dotnet应用程序启动器组成：
CoreCLR，也称为.NETCore运行时，是.NETCore的核心，是CLR的跨平台实现；原始的.NETFrameworkCLR已经重构为CoreCLR。CoreCLR，即公共语言运行时，管理对象的使用和引用，不同编程语言中的对象的通信和交互，并通过在对象不再使用时释放内存来执行垃圾收集。CoreCLR包括以下内容：
CoreFX是.NETCore的一组框架或基础库，它提供原始数据类型、文件系统、应用程序组合类型、控制台和基本实用工具。CoreFX包含了一系列精简的类库。
.NETCoreSDK包含一组工具，包括命令行界面（CLI）工具和编译器，用于构建应用程序和库在.NETCore上运行。SDK工具和语言编译器提供功能，通过CoreFX库支持的语言组件，使编码更加简单和快速。
为了启动一个.NETCore应用程序，dotnet应用程序主机是负责选择和托管应用程序所需运行时的组件。.NETCore有控制台应用程序作为主要应用程序模型，以及其他应用程序模型，如ASP.NETCore、Windows10通用Windows平台和XamarinForms。
.NETCore1.0仅支持C#和F#，但随着.NETCore2.0的发布，VB.NET现在也受到了平台的支持。支持的语言的编译器在.NETCore上运行，并提供对平台基础功能的访问。这是可能的，因为.NETCore实现了.NET标准规范，并公开了.NETFramework中可用的API。支持的语言和.NETSDK工具可以集成到不同的编辑器和IDE中，为您提供不同的编辑器选项，用于开发应用程序。
.NETCore和.NETFramework都非常适合用于开发健壮和可扩展的企业应用程序；这是因为这两个平台都建立在坚实的代码基础上，并提供了丰富的库和例程，简化了大多数开发任务。这两个平台共享许多相似的组件，因此可以在两个开发平台之间共享代码。然而，这两个平台是不同的，选择.NETCore作为首选的开发平台应受开发方法以及部署需求和要求的影响。
显然，当您开发的应用程序要在多个平台上运行时，应该使用.NETCore。由于.NETCore是跨平台的，因此适用于开发可以在Windows、Linux和macOS上运行的服务和Web应用程序。此外，微软推出了VisualStudioCode，这是一个具有对.NETCore的全面支持的编辑器，提供智能感知和调试功能，以及传统上仅在VisualStudioIDE中可用的其他IDE功能。
使用.NETCore，开发使用微服务架构的应用程序相对较容易。使用微服务架构，您可以开发使用不同技术混合的应用程序，例如使用PHP、Java或Rails开发的服务。您可以使用.NETCore开发微服务，以部署到云平台或容器中。使用.NETCore，您可以开发可扩展的应用程序，可以在高性能计算机或高端服务器上运行，从而使您的应用程序可以轻松为数十万用户提供服务。
虽然.NETCore是强大的、易于使用的，并在应用程序开发中提供了几个好处，但它目前并不适用于所有的开发问题和场景。微软从.NETFramework中删除了几项技术，以使.NETCore变得简化和跨平台。因此，这些技术在.NETCore中不可用。
当您的应用程序将使用.NETCore中不可用的技术时，例如在表示层使用WPF或WindowsForms，WCF服务器实现，甚至目前没有.NETCore版本的第三方库，建议您使用.NETFramework开发应用程序。
随着.NETCore2.0的发布，添加了新的模板，为可以在平台上运行的不同应用程序类型提供了更多选项。除了现有的项目模板之外，还添加了以下单页应用程序（SPA）模板：
.NETCore中的控制台应用程序与.NETFramework具有类似的结构，而ASP.NETCore具有一些新组件，包括以前版本的ASP.NET中没有的文件夹和文件。
多年来，ASP.NETWeb框架已经完全成熟，从Web表单过渡到MVC和WebAPI。ASP.NETCore是一个新的Web框架，用于开发可以在.NETCore上运行的Web应用程序和WebAPI。它是ASP.NET的精简和更简化版本，易于部署，并具有内置的依赖注入。ASP.NETCore可以与AngularJS、Bootstrap和ReactJS等框架集成。
ASP.NETCoreMVC，类似于ASP.NETMVC，是构建Web应用程序和API的框架，使用模型视图控制器模式。与ASP.NETMVC一样，它支持模型绑定和验证，标签助手，并使用Razor语法用于Razor页面和MVC视图。
ASP.NETCoreMVC应用程序的结构与ASP.NETMVC不同，添加了新的文件夹和文件。当您从VisualStudio2017，VisualStudioforMac或通过解决方案资源管理器中的CLI工具创建新的ASP.NETCore项目时，您可以看到添加到项目结构的新组件。
在ASP.NETCore中，新添加的wwwroot文件夹用于保存库和静态内容，例如图像，JavaScript文件和库，以及CSS和HTML，以便轻松访问并直接提供给Web客户端。wwwroot文件夹包含.css，图像，.js和.lib文件夹，用于组织站点的静态内容。
与ASP.NETMVC项目类似，ASP.NETMVC核心应用程序的根文件夹也包含模型，视图和控制器，遵循MVC模式的约定，以正确分离Web应用程序文件，代码和表示逻辑。
引入的一些其他文件包括appsettings.json，其中包含所有应用程序设置，bower.json，其中包含用于管理项目中使用的客户端包括CSS和JavaScript框架的条目，以及bundleconfig.json，其中包含用于配置项目的捆绑和最小化的条目。
与C#控制台应用程序类似，ASP.NETCore具有Program类，这是一个重要的类，包含应用程序的入口点。该文件具有用于运行应用程序的Main()方法，并用于创建WebHostBuilder的实例，用于创建应用程序的主机。在Main方法中指定要由应用程序使用的Startup类：
publicclassProgram{publicstaticvoidMain(string[]args){BuildWebHost(args).Run();}publicstaticIWebHostBuildWebHost(string[]args)=>WebHost.CreateDefaultBuilder(args).UseStartup
不同的Startup类可以为不同的环境创建；例如，您可以在应用程序中创建两个Startup类，一个用于开发环境，另一个用于生产环境。您还可以指定一个Startup类用于所有环境。
Startup类有两个方法——Configure()，这是必须的，用于确定应用程序如何响应HTTP请求，以及ConfigureServices()，这是可选的，用于在调用Configure方法之前配置服务。这两种方法在应用程序启动时都会被调用：
publicclassStartup{publicStartup(IConfigurationconfiguration){Configuration=configuration;}publicIConfigurationConfiguration{get;}//Thismethodgetscalledbytheruntime.Usethismethodtoaddservicestothecontainer.publicvoidConfigureServices(IServiceCollectionservices){services.AddMvc();}//Thismethodgetscalledbytheruntime.UsethismethodtoconfiguretheHTTPrequestpipeline.publicvoidConfigure(IApplicationBuilderapp,IHostingEnvironmentenv){if(env.IsDevelopment()){app.UseDeveloperExceptionPage();}else{app.UseExceptionHandler("/Home/Error");}app.UseStaticFiles();app.UseMvc(routes=>{routes.MapRoute(name:"default",template:"{controller=Home}/{action=Index}/{id}");});}}微软的VisualStudioCode编辑器之旅开发.NETCore应用程序变得更加容易，不仅因为平台的流畅性和健壮性，还因为引入了VisualStudioCode，这是一个跨平台编辑器，可以在Windows、Linux和macOS上运行。在创建.NETCore应用程序之前，您不需要在系统上安装VisualStudioIDE。
VisualStudioCode虽然没有VisualStudioIDE那么强大和功能丰富，但确实具有内置的生产力工具和功能，使得使用它轻松创建.NETCore应用程序。您还可以在VisualStudioCode中安装用于多种编程语言的扩展，从VisualStudioMarketplace中获取，从而可以灵活地编辑其他编程语言编写的代码。
为了展示.NETCore的跨平台功能，让我们在Ubuntu17.04桌面版上设置.NETCore开发环境。在安装VisualStudioCode之前，让我们在UbuntuOS上安装.NETCore。首先，您需要通过在添加Microsoft产品feed之前注册Microsoft签名密钥来进行一次性注册：
cd/home/user/Documents/testappdotnetnewconsole这将产生以下输出：
由于VisualStudioCode是一个跨平台编辑器，可以安装在许多LinuxOS的变体上，逐渐添加其他Linux发行版的软件包。要在Ubuntu上安装VisualStudioCode，请执行以下步骤：
sudodpkg-i
当您启动VisualStudioCode时，它会加载上次关闭时的状态，打开您上次访问的文件和文件夹。编辑器的布局易于导航和使用，并带有诸如：
多年来，C#编程语言已经成熟；随着每个版本的发布，越来越多的语言特性和构造被添加进来。这门语言最初只是由微软内部开发，并且只能在Windows操作系统上运行，现在已经成为开源和跨平台。这是通过.NETCore和语言的7版（7.0和7.1）实现的，它增加了语言的特色并改进了可用的功能。特别是语言的7.2版和8.0版的路线图承诺为语言增加更多功能。
元组在C#语言中的第4版中引入，并以简化形式使用，以提供具有两个或更多数据元素的结构，允许您创建可以返回两个或更多数据元素的方法。在C#7之前，引用元组的元素是通过使用Item1，Item2，...ItemN来完成的，其中N是元组结构中元素的数量。从C#7开始，元组现在支持包含字段的语义命名，引入了更清晰和更有效的创建和使用元组的方法。
您现在可以通过直接为每个成员分配一个值来创建元组。此赋值将创建一个包含元素Item1，Item2的元组：
varnames=("John","Doe");您还可以创建具有元组中包含的元素的语义名称的元组：
(stringfirstName,stringlastName)names=("John","Doe");元组的名称，而不是具有Item1，Item2等字段，将在编译时具有可以作为firstName和lastName引用的字段。
当使用POCO可能过于繁琐时，您可以创建自己的方法来返回具有两个或更多数据元素的元组：
classProgram{staticvoidMain(string[]args){GetNames(outstringfirstName,outstringlastName);}privatestaticvoidGetNames(outstringfirstName,outstringlastName){firstName="John";lastName="Doe";}}语言中已添加了对隐式类型输出变量的支持，允许编译器推断变量的类型：
publicrefstringGetFifthDayOfWeek(){string[]daysOfWeek=newstring[7]{"Monday","Tuesday","Wednesday","Thursday","Friday","Saturday","Sunday"};returnrefdaysOfWeek[4];}局部函数局部或嵌套函数允许您在另一个函数内定义一个函数。这个特性在一些编程语言中已经有很多年了，但是在C#7中才刚刚引入。当您需要一个小型且在container方法的上下文之外不可重用的函数时，这是一个理想的选择：
classProgram{staticvoidMain(string[]args){GetNames(outvarfirstName,outvarlastName);voidGetNames(outstringfirstName,outstringlastName){firstName="John";lastName="Doe";}}}模式匹配C#7包括模式，这是一种语言元素特性，允许您在除了对象类型之外的属性上执行方法分派。它扩展了已经在覆盖和虚拟方法中实现的语言构造，用于实现类型和数据元素的分派。在语言的7.0版本中，is和switch表达式已经更新以支持模式匹配，因此您现在可以使用这些表达式来确定感兴趣的对象是否具有特定模式。
引入的模式匹配可以采用三种形式：
publicvoidProcessLoan(Loanloan){if(loanisCarLoancarLoan){//dosomething}}publicvoidProcessLoan(Loanloan){if(loanisvarcarLoan){//dosomething}}publicvoidProcessLoan(Loanloan){if(loanisnull){//dosomething}}通过更新的switch表达式，您现在可以在case语句中使用模式和条件，并且可以在除了基本或原始类型之外的任何类型上进行switch，同时允许您使用when关键字来额外指定模式的规则：
publicvoidProcessLoan(Loanloan){switch(loan){caseCarLoancarLoan://dosomethingbreak;caseHouseLoanhouseLoanwhen(houseLoan.IsElligible==true)://dosomethingbreak;casenull://throwsomecustomexceptionbreak;default://dosomething}}数字分隔符和二进制字面量在C#7中添加了一种新的语法糖，即数字分隔符。这种构造极大地提高了代码的可读性，特别是在处理C#支持的不同数值类型的大量数字时。在C#7之前，操作大数值以添加分隔符有点混乱和难以阅读。引入数字分隔符后，您现在可以使用下划线（_）作为数字的分隔符：
varlongDigit=2_300_400_500_78;在这个版本中还新增了二进制字面量。现在可以通过简单地在二进制值前加上0b来创建二进制字面量：
varbinaryValue=0b11101011;创建一个ASP.NETMVCCore应用程序ASP.NETCore提供了一种优雅的方式来构建在Windows、Linux和macOS上运行的Web应用程序和API，这要归功于.NETCore平台的工具和SDK，这些工具和SDK简化了开发尖端应用程序并支持应用程序版本的并行。使用ASP.NETCore，您的应用程序的表面积更小，这可以提高性能，因为您只需要包含运行应用程序所需的NuGet包。ASP.NETCore还可以与客户端库和框架集成，允许您使用您已经熟悉的CSS和JS库来开发Web应用程序。
ASP.NETCore使用Kestrel运行，Kestrel是包含在ASP.NETCore项目模板中的Web服务器。Kestrel是一个基于libuv的进程内跨平台HTTP服务器实现，libuv是一个跨平台的异步I/O库，使构建和调试ASP.NETCore应用程序变得更加容易。它监听HTTP请求，然后将请求的详细信息和特性打包到一个HttpContext对象中。Kestrel可以作为独立的Web服务器使用，也可以与IIS或ApacheWeb服务器一起使用，其他Web服务器接收到的请求将被转发到Kestrel，这个概念被称为反向代理。
ASP.NETMVCCore为您提供了一个可测试的框架，用于使用ModelViewController模式进行现代Web应用程序开发，这使您可以充分实践测试驱动开发。在ASP.NET2.0中新增的是对Razor页面的支持，这现在是开发ASP.NETCoreWeb应用程序用户界面的推荐方法。
要创建一个新的ASP.NETMVCCore项目：
.NETCore平台虽然新，但正在迅速成熟，2.0.7版本引入了许多功能和增强功能，简化了构建不同类型的跨平台应用程序。在本章中，我们已经对平台进行了介绍，介绍了C#7的新功能，并在UbuntuLinux上设置了开发环境，同时创建了我们的第一个ASP.NETMVCCore应用程序。
在下一章中，我们将解释要注意避免编写不可测试代码，并且我们将带领您了解可以帮助您编写可测试和高质量代码的SOLID原则。
在第一章中，探索测试驱动开发，解释了编写代码以防止代码异味的陷阱。编写良好的代码本身就是一种艺术，而编写可以有效测试的代码的过程需要开发人员额外的努力和承诺，以编写可以反复测试而不费吹灰之力的干净代码。
编写测试和编写主要代码一样重要。为不可测试的代码编写测试非常累人且非常困难，这就是为什么首先应该避免不可测试的代码的原因。代码之所以不可测试，可能有不同的原因，比如代码做得太多（怪兽代码），违反了单一职责原则，架构使用错误，或者面向对象设计有缺陷。
有效和持续的TDD实践可以改善编写代码的过程，使测试变得更容易，从而提高代码质量和软件应用的健壮性。然而，当项目的代码库包含不可测试的代码部分时，编写单元测试或集成测试变得极其困难，甚至几乎不可能。
当软件项目的代码库中存在不可测试的代码时，软件开发团队无法明确验证应用程序功能和特性的一致行为。为了避免这种可预防的情况，编写可测试的代码不是一个选择，而是每个重视质量软件的严肃开发团队的必须。
不可测试的代码是由于违反了已被证明和测试可以提高代码质量的常见标准、实践和原则而产生的。虽然专业素养随着良好实践和经验的反复使用而来，但有一些常见的糟糕代码设计和编写方法即使对于初学者来说也是常识，比如在不需要时使用全局变量、代码的紧耦合、硬编码依赖关系或可能在代码中发生变化的值。
在本节中，我们将讨论一些常见的反模式和陷阱，当编写代码时应该注意，因为它们可能会使为生产代码编写测试变得困难。
具有紧密耦合依赖关系的单元测试代码将导致测试紧密耦合的不同对象。在单元测试期间，应该在构造函数中注入的依赖关系理想情况下应该很容易模拟，但这将是不可能的。这通常会减慢整体测试过程，因为所有依赖关系都必须在受测试的代码中构建。
在以下代码片段中，LoanProcessor与EligibilityChecker紧密耦合。这是因为EligibilityChecker在LoanProcessor构造函数中使用了new关键字进行实例化。对EligibilityChecker的更改将影响LoanProcessor，可能导致其出现故障。此外，对LoanProcessor中包含的任何方法进行单元测试都将导致EligibilityChecker被构造：
publicclassLoanProcessor{privateEligibilityCheckereligibilityChecker;publicLoanProcessor(){eligibilityChecker=newEligibilityChecker();}publicvoidProcessCustomerLoan(Loanloan){thrownewNotImplementedException();}}解决LoanProcessor中紧密耦合的一种方法是使用依赖注入（DI）。由于LoanProcessor无法在隔离环境中进行测试，因为EligibilityChecker对象将必须在构造函数中实例化，所以可以通过构造函数将EligibilityChecker注入到LoanProcessor中：
publicclassLoanProcessor{privateEligibilityCheckereligibilityChecker;publicLoanProcessor(EligibilityCheckereligibilityChecker){this.eligibilityChecker=eligibilityChecker;}publicvoidProcessCustomerLoan(Loanloan){boolisEligible=eligibilityChecker.CheckLoan(loan);thrownewNotImplementedException();}}通过注入EligibilityChecker，测试LoanProcessor变得更容易，因为这使您可以编写一个测试，其中模拟EligibilityChecker的实现，从而允许您在隔离环境中测试LoanProcessor。
另外，可以通过LoanProcessor类的属性或成员注入EligibilityChecker，而不是通过LoanProcessor构造函数传递依赖项：
publicclassLoanProcessor{privateEligibilityCheckereligibilityChecker;publicEligibilityCheckerEligibilityCheckerObject{set{eligibilityChecker=value;}}publicvoidProcessCustomerLoan(Loanloan){boolisEligible=eligibilityChecker.CheckLoan(eligibilityChecker);thrownewNotImplementedException();}}通过构造函数或属性注入依赖后，LoanProcessor和EligibilityChecker现在变得松散耦合，从而使得编写单元测试和模拟EligibilityChecker变得容易。
要使类松散耦合且可测试，必须确保该类不实例化其他类和对象。在类的构造函数或方法中实例化对象可能会导致无法注入模拟或虚拟对象，从而使代码无法进行测试。
要测试一个方法，您必须实例化或构造包含该方法的类。开发人员最常见的错误之一是创建我所谓的怪物构造函数，它只是一个做了太多工作或真正工作的构造函数，比如执行I/O操作、数据库调用、静态初始化、读取一些大文件或与外部服务建立通信。
当一个类设计有一个构造函数，用于初始化或实例化除值对象（列表、数组和字典）之外的对象时，该类在技术上具有非灵活的结构。这是糟糕的类设计，因为该类自动与其实例化的类紧密耦合，使得单元测试变得困难。具有这种设计的任何类也违反了单一责任原则，因为对象图的创建是可以委托给另一个类的责任。
在具有做大量工作的构造函数的类中测试方法会带来巨大的成本。实质上，要测试具有上述设计的类中的方法，您被迫要经历在构造函数中创建依赖对象的痛苦。如果依赖对象在构造时进行数据库调用，那么每次测试该类中的方法时，这个调用都会被重复，使得测试变得缓慢和痛苦：
publicclassLoanProcessor{privateEligibilityCheckereligibilityChecker;privateCurrencyConvertercurrencyConverter;publicLoanProcessor(){eligibilityChecker=newEligibilityChecker();currencyConverter=newCurrencyConverter();currencyConverter.DownloadCurrentRates();eligibilityChecker.CurrentRates=currencyConverter.Rates;}}在上述代码片段中，对象图的构建是在LoanProcessor构造函数中完成的，这肯定会使得该类难以测试。最好的做法是拥有一个精简的构造函数，它做很少的工作，并且对其他对象的了解很少，特别是它们能做什么，但不知道它们是如何做到的。
有时开发人员使用一种测试技巧，即为一个类创建多个构造函数。其中一个构造函数将被指定为仅用于测试的构造函数。虽然使用这种方法可以使类在隔离环境中进行测试，但也存在不好的一面。例如，使用多个构造函数创建的类可能会被其他类引用，并使用做大量工作的构造函数进行实例化。这可能会使得测试这些依赖类变得非常困难。
以下代码片段说明了为了测试类而创建单独构造函数的糟糕设计：
publicclassLoanProcessor{privateEligibilityCheckereligibilityChecker;privateCurrencyConvertercurrencyConverter;publicLoanProcessor(){eligibilityChecker=newEligibilityChecker();currencyConverter=newCurrencyConverter();currencyConverter.DownloadCurrentRates();eligibilityChecker.CurrentRates=currencyConverter.Rates;}//constructorfortestingpublicLoanProcessor(EligibilityCheckereligibilityChecker,CurrencyConvertercurrencyConverter){this.eligibilityChecker=eligibilityChecker;this.currencyConverter=currencyConverter;}}有一些重要的警告信号可以帮助您设计一个构造函数工作量较小的松散耦合类。避免在构造函数中使用new操作符，以允许注入依赖对象。您应该初始化并分配通过构造函数注入的所有对象到适当的字段中。轻量级值对象的实例化也应该在构造函数中完成。
此外，应避免静态方法调用，因为静态调用无法被注入或模拟。此外，应避免在构造函数中使用迭代或条件逻辑；每次测试类时，逻辑或循环都将被执行，导致过多的开销。
在设计类时要考虑测试，不要在构造函数中创建依赖对象或协作者。当您的类需要依赖其他类时，请注入依赖项。确保只创建值对象。在代码中创建对象图时，使用工厂方法来实现。工厂方法用于创建对象。
理想情况下，一个类应该只有一个责任。当您设计的类具有多个责任时，可能会在类之间产生交互，使得代码修改变得困难，并且几乎不可能对交互进行隔离测试。
有一些指标可以清楚地表明一个类做了太多事情并且具有多个责任。例如，当您在为一个类命名时感到困难，最终可能会在类名中使用and这个词，这表明该类做了太多事情。
一个具有多个责任的类的另一个标志是，类中的字段仅在某些方法中使用，或者类具有仅对参数而不是类字段进行操作的静态方法。此外，当一个类具有长列表的字段或方法以及许多依赖对象传递到类构造函数中时，表示该类做了太多事情。
在以下片段中，LoanProcessor类的依赖项已经整洁地注入到构造函数中，使其与依赖项松散耦合。然而，该类有多个改变的原因；该类既包含用于数据检索的代码，又包含业务规则处理的代码：
publicclassLoanProcessor{privateEligibilityCheckereligibilityChecker;privateDbContextdbContext;publicLoanProcessor(EligibilityCheckereligibilityChecker,DbContextdbContext){this.eligibilityChecker=eligibilityChecker;this.dbContext=dbContext;}publicdoubleCalculateCarLoanRate(Loanloan){doublerate=12.5F;boolisEligible=eligibilityChecker.IsApplicantEligible(loan);if(isEligible)rate=rate-loan.DiscountFactor;returnrate;}publicList
具有本节描述的特征的类可能很难进行调试和测试。新团队成员可能很难快速理解类的内部工作原理。如果您的代码库中有具有这些属性的类，建议通过识别责任并将其分离到不同的类中，并根据其责任命名类来进行重构。
在代码中使用静态变量、方法和对象可能是有用的，因为这些允许对象在所有实例中具有相同的值，因为只创建了一个对象的副本并放入内存中。然而，测试包含静态内容的代码，特别是静态方法的代码，可能会产生测试问题，因为您无法在子类中覆盖静态方法，并且使用模拟框架来模拟静态方法是一项非常艰巨的任务：
publicstaticclassLoanProcessor{privatestaticEligibilityCheckereligibilityChecker=newEligibilityChecker();publicstaticdoubleCalculateCarLoanRate(Loanloan){doublerate=12.5F;boolisEligible=eligibilityChecker.IsApplicantEligible(loan);if(isEligible)rate=rate-loan.DiscountFactor;returnrate;}}当您创建维护状态的静态方法时，例如在前面片段中的LoanProcessor中的CalculateCarLoanRate方法，静态方法无法通过多态进行子类化或扩展。此外，静态方法无法使用接口进行定义，因此使得模拟变得不可能，因为大多数模拟框架都有效地使用接口。
在软件编程中，技术上没有严格遵循的硬性法律。然而，已经制定了各种原则和法律，作为指导方针，可以帮助软件开发人员和从业者，促进构建具有高内聚性和松耦合性的组件的软件应用程序，以充分封装数据，并确保产生易于理解和扩展的高质量源代码，从而降低软件的维护成本。其中之一就是迪米特法则（LoD）。
LoD，也称为最少知识原则，是开发面向对象软件应用程序的重要设计方法或规则。该规则于1987年由IanHolland在东北大学制定。通过正确理解这一原则，软件开发人员可以编写易于测试的代码，并构建具有更少或没有错误的软件应用程序。该法则的制定是：
LoD作为软件开发人员的启发式，以促进软件模块和组件中的信息隐藏。LoD有两种形式——对象或动态形式和类或静态形式。
LoD的类形式被公式化为：
类（C）的方法（M）只能向以下类的对象发送消息：
LoD的对象形式被公式化为：
在M中，消息只能发送到以下对象：
publicclassLoanProcessor{privateCurrencyConvertercurrencyConverter;publicLoanProcessor(LoanCalculatorloanCalculator){currencyConverter=loanCalculator.GetCurrencyConverter();}}前面的代码明显违反了LoD，这是因为LoanProcessor实际上并不关心LoanCalculator，因为它没有保留任何对它的引用。在代码中，LoanProcessor已经在与LoanCalculator进行交流，一个陌生人。这段代码实际上并不可重用，因为任何试图重用它们的类或代码都将需要CurrencyConverter和LoanProcessor，尽管从技术上讲，LoanCalculator在构造函数之外并未被使用。
为了对LoanProcessor编写单元测试，需要创建对象图。必须创建LoanCalculator以便CurrencyConverter可用。这会在系统中创建耦合，如果LoanCalculator被重构，这是可能的，那么可能会导致LoanProcessor出现故障，导致单元测试停止运行。
LoanCalculator类可以被模拟，以便单独测试LoanProcessor，但这有时会使测试变得难以阅读，最好避免耦合，这样可以编写灵活且易于测试的代码。
要重构前面的代码片段，并使其符合LoD并从类构造函数中获取其依赖项，从而消除对LoanCalculator的额外依赖，并减少代码的耦合：
loanCalculator.CalculateHouseLoan(loanDTO).GetPaymentRate().GetMaximumYearsToPay();你可能想知道这种现象如何违反了LoD。首先，代码缺乏可读性，不易维护。此外，代码行不可重用，因为一行代码中有三个方法调用。
这行代码可以通过减少交互和消除方法链来进行重构，以使其符合“不要和陌生人说话”的原则。这个原则解释了调用点或方法应该一次只与一个对象交互。通过消除方法链，生成的代码可以在其他地方重复使用，而不必费力理解代码的作用：
varhouseLoan=loanCalculator.CalculateHouseLoan(loanDTO);varpaymentRate=houseLoan.GetPaymentRate();varmaximumYears=paymentRate.GetMaximumYearsToPay();一个对象应该对其他对象的知识和信息有限。此外，对象中的方法应该对应用程序的对象图具有很少的认识。通过有意识的努力，使用LoD，你可以构建松散耦合且易于维护的软件应用程序。
软件应用程序开发的程序和方法，从第一步到最后一步，应该简单易懂，无论是新手还是专家都能理解。这些程序，当与正确的原则结合使用时，使开发和维护软件应用程序的过程变得简单和无缝。
开发人员不时采用和使用不同的开发原则和模式，以简化复杂性并使软件应用程序代码库易于维护。其中一个原则就是SOLID原则。这个原则已经被证明非常有用，是每个面向对象系统的严肃程序员必须了解的。
SOLID是开发面向对象系统的五个基本原则的首字母缩写。这五个原则是用于类设计的，表示为：
这些原则首次被整合成SOLID的首字母缩写，并在2000年代初由罗伯特·C·马丁（通常被称为鲍勃叔叔）推广。这五个原则是用于类设计的，遵守这些原则可以帮助管理依赖关系，避免创建混乱的、到处都是依赖的僵化代码库。
对SOLID原则的正确理解和运用可以使软件开发人员实现非常高的内聚度，并编写易于理解和维护的高质量代码。有了SOLID原则，你可以编写干净的代码，构建健壮且可扩展的软件应用程序。
事实上，鲍勃叔叔澄清了SOLID原则不是法律或规则，而是已经观察到在几种情况下起作用的启发式。要有效地使用这些原则，你必须搜索你的代码，检查违反原则的部分，然后进行重构。
单一职责原则（SRP）是五个SOLID原则中的第一个。该原则规定一个类在任何时候只能有一个改变的理由。这简单地意味着一个类一次只能执行一个职责或有一个责任。
软件项目的业务需求通常不是固定的。在软件项目发布之前，甚至在软件的整个生命周期中，需求会不时地发生变化，开发人员必须根据变化调整代码库。为了使软件应用程序满足其业务需求并适应变化，必须使用灵活的设计模式，并且类始终只有一个责任。
此外，重要的是要理解，当一个类有多个责任时，即使进行最微小的更改也会对整个代码库产生巨大影响。对类的更改可能会导致连锁反应，导致之前工作的功能或其他方法出现故障。例如，如果你有一个解析.csv文件的类，同时它还调用一个Web服务来检索与.csv文件解析无关的信息，那么这个类就有多个改变的原因。对Web服务调用的更改将影响该类，尽管这些更改与.csv文件解析无关。
以下代码片段中的LoanCalculator类的设计明显违反了SRP。LoanCalculator有两个责任——第一个是计算房屋和汽车贷款，第二个是从XML文件和XML字符串中解析贷款利率：
责任不应该混在一个类中。你应该避免在一个类中混淆责任，这会导致做太多事情的怪兽类。相反，如果你能想到一个改变类的理由或动机，那么它已经有了多个责任；将类分成每个只包含单一责任的类。
publicclassLoanService{privateIEligibilityCheckereligibilityChecker;publicLoanService(IEligibilityCheckereligibilityChecker){this.eligibilityChecker=eligibilityChecker;}publicdoubleCalculateCarLoanRate(CarLoancarLoan){doublerate=12.5F;boolisEligible=eligibilityChecker.IsApplicantEligible(carLoan);if(isEligible)rate=rate-carLoan.DiscountFactor;returnrate;}}通过将业务逻辑代码分离到LoanService类中，LoanRepository类现在只有一个依赖，即DbContext实体框架。未来，LoanRepository可以很容易地进行维护和测试。新的LoanService类也符合SRP：
publicclassLoanRepository{privateDbContextdbContext;publicLoanRepository(DbContextdbContext){this.dbContext=dbContext;}publicList
设计和最终编写生产代码的方法应该是允许向项目的代码库添加新功能，而无需进行多次更改、更改代码库的几个部分或类，或破坏已经正常工作且状态良好的现有功能。
如果由于对类中的方法进行更改而导致必须对多个部分或模块进行更改，这表明代码设计存在问题。这就是开闭原则（OCP）所解决的问题，允许您的代码库设计灵活，以便您可以轻松进行修改和增强。
OCP规定软件实体（如类、方法和模块）应设计为对扩展开放，但对修改关闭。这个原则可以通过继承或设计模式（如工厂、观察者和策略模式）来实现。这是指类和方法可以被设计为允许添加新功能，以供现有代码使用，而无需实际修改或更改现有代码，而是通过扩展现有代码的行为。
在C#中，通过正确使用对象抽象，您可以拥有封闭的类，这些类对修改关闭，而类的行为可以通过派生类进行扩展。派生类是封闭类的子类。使用继承，您可以创建通过扩展其基类添加更多功能的类，而无需修改基类。
考虑以下代码片段中的LoanCalculator类，它具有一个CalculateLoan方法，必须能够计算传递给它的任何类型的贷款的详细信息。在不使用OCP的情况下，可以使用if..elseif语句来计算要求。
LoanCalculator类具有严格的结构，当需要支持新类型时需要进行大量工作。例如，如果您打算添加更多类型的客户贷款，您必须修改CalculateLoan方法并添加额外的elseif语句以适应新类型的贷款。LoanCalculator违反了OCP，因为该类不是封闭的以进行修改：
publicclassLoanCalculator{privateIRateParserrateParser;publicLoanCalculator(IRateParserrateParser){this.rateParser=rateParser;}publicLoanCalculateLoan(LoanDTOloanDTO){Loanloan=newLoan();if(loanDTO.LoanType==LoanType.CarLoan){loan.LoanType=LoanType.CarLoan;loan.InterestRate=rateParser.GetRateByLoanType(LoanType.CarLoan);//dootherprocessing}elseif(loanDTO.LoanType==LoanType.HouseLoan){loan.LoanType=LoanType.HouseLoan;loan.InterestRate=rateParser.GetRateByLoanType(LoanType.HouseLoan);//dootherprocessing}returnloan;}}为了使LoanCalculator类对扩展开放而对修改关闭，我们可以使用继承来简化重构。LoanCalculator将被重构以允许从中创建子类。将LoanCalculator作为基类将有助于创建两个派生类，HouseLoanCalculator和CarLoanCalulator。计算不同类型贷款的业务逻辑已从CalculateLoan方法中移除，并在两个派生类中实现，如下面的代码片段所示：
publicclassLoanCalculator{protectedIRateParserrateParser;publicLoanCalculator(IRateParserrateParser){this.rateParser=rateParser;}publicLoanCalculateLoan(LoanDTOloanDTO){Loanloan=newLoan();//dosomebaseprocessingreturnloan;}}LoanCalculator类中的If条件已从CalculateLoan方法中移除。现在，新的CarLoanCaculator类包含了获取汽车贷款计算的逻辑：
publicclassCarLoanCalculator:LoanCalculator{publicCarLoanCalculator(IRateParserrateParser):base(rateParser){base.rateParser=rateParser;}publicoverrideLoanCalculateLoan(LoanDTOloanDTO){Loanloan=newLoan();loan.LoanType=loanDTO.LoanType;loan.InterestRate=rateParser.GetRateByLoanType(loanDTO.LoanType);//dootherprocessingreturnloan}}HouseLoanCalculator类是从LoanCalculator创建的，具有覆盖基类LoanCalculator中的CalculateLoan方法的CalculateLoan方法。对HouseLoanCalculator进行的任何更改都不会影响其基类的CalculateLoan方法：
publicclassHouseLoanCalculator:LoanCalculator{publicHouseLoanCalculator(IRateParserrateParser):base(rateParser){base.rateParser=rateParser;}publicoverrideLoanCalculateLoan(LoanDTOloanDTO){Loanloan=newLoan();loan.LoanType=LoanType.HouseLoan;loan.InterestRate=rateParser.GetRateByLoanType(LoanType.HouseLoan);//dootherprocessingreturnloan;}}如果引入了新类型的贷款，比如研究生学习贷款，可以创建一个新类PostGraduateStudyLoan来扩展LoanCalculator并实现CalculateLoan方法，而无需对LoanCalculator类进行任何修改。
从技术上讲，观察OCP意味着您的代码中的类和方法应该对扩展开放，这意味着可以扩展类和方法以添加新的行为来支持新的或不断变化的应用程序需求。而且类和方法对于修改是封闭的，这意味着您不能对源代码进行更改。
为了使LoanCalculator对更改开放，我们将其作为其他类型的基类派生。或者，我们可以创建一个ILoanCalculator抽象，而不是使用经典的对象继承：
publicinterfaceILoanCalculator{LoanCalculateLoan(LoanDTOloanDTO);}CarLoanCalculator类现在可以被创建来实现ILoanCalculator接口。这将需要CarLoanCalculator类明确实现接口中定义的方法和属性。
publicclassCarLoanCalculator:ILoanCalculator{privateIRateParserrateParser;publicCarLoanCalculator(IRateParserrateParser){this.rateParser=rateParser;}publicLoanCalculateLoan(LoanDTOloanDTO){Loanloan=newLoan();loan.LoanType=loanDTO.LoanType;loan.InterestRate=rateParser.GetRateByLoanType(loanDTO.LoanType);//dootherprocessingreturnloan}}HouseLoanCalculator类也可以被创建来实现ILoanCalculator，通过构造函数将IRateParser对象注入其中，类似于CarLoanCalculator。CalculateLoan方法可以被实现为具有计算房屋贷款所需的特定代码。通过简单地创建类并使其实现ILoanCalculator接口，可以添加任何其他类型的贷款：
publicclassHouseLoanCalculator:ILoanCalculator{privateIRateParserrateParser;publicHouseLoanCalculator(IRateParserrateParser){this.rateParser=rateParser;}publicLoanCalculateLoan(LoanDTOloanDTO){Loanloan=newLoan();loan.LoanType=loanDTO.LoanType;loan.InterestRate=rateParser.GetRateByLoanType(loanDTO.LoanType);//dootherprocessingreturnloan}}使用OCP，您可以创建灵活的软件应用程序，其行为可以轻松扩展，从而避免代码基础僵化且缺乏可重用性。通过适当使用OCP，通过有效使用代码抽象和对象多态性，可以对代码基础进行更改，而无需更改许多部分，并且付出很少的努力。您真的不必重新编译代码基础来实现这一点。
Liskov替换原则（LSP），有时也称为按合同设计，是SOLID原则中的第三个原则，最初由BarbaraLiskov提出。LSP规定，派生类或子类应该可以替换基类或超类，而无需对基类进行修改或在系统中生成任何运行时错误。
LSP可以通过以下数学符号进一步解释——假设S是T的子集，T的对象可以替换S的对象，而不会破坏系统的现有工作功能或引起任何类型的错误。
为了说明LSP的概念，让我们考虑一个带有Drive方法的Car超类。如果Car有两个派生类，SalonCar和JeepCar，它们都有Drive方法的重写实现，那么无论何时需要Car，都应该可以使用SalonCar和JeepCar来替代Car类。派生类与Car有一个是一个的关系，因为SalonCar是Car，JeepCar是Car。
为了设计您的类并实现它们以符合LSP，您应该确保派生类的元素是按照合同设计的。派生类的方法定义应该与基类的相似，尽管实现可能会有所不同，因为不同的业务需求。
此外，重要的是派生类的实现不违反基类或接口中实现的任何约束。当您部分实现接口或基类时，通过具有未实现的方法，您正在违反LSP。
以下代码片段具有LoanCalculator基类，具有CalculateLoan方法和两个派生类，HouseLoanCalculator和CarLoanCalculator，它们具有CalculateLoan方法并且可以具有不同的实现：
publicclassLoanCalculator{publicLoanCalculateLoan(LoanDTOloanDTO){thrownewNotImplementedException();}}publicclassHouseLoanCalculator:LoanCalculator{publicoverrideLoanCalculateLoan(LoanDTOloanDTO){thrownewNotImplementedException();}}publicclassCarLoanCalculator:LoanCalculator{publicoverrideLoanCalculateLoan(LoanDTOloanDTO){thrownewNotImplementedException();}}如果在前面的代码片段中没有违反LSP，那么HouseLoanCalculator和CarLoanCalculator派生类可以在需要LoanCalculator引用的任何地方使用。这在以下代码片段中的Main方法中得到了证明：
接口隔离原则（ISP）规定接口应该是适度的，只包含所需的属性和方法的定义，客户端不应被强制实现他们不使用的接口，或依赖他们不需要的方法。
要有效地在代码库中实现ISP，您应该倾向于创建简单而薄的接口，这些接口具有逻辑上分组在一起以解决特定业务案例的方法。通过创建薄接口，类代码中包含的方法可以轻松实现，同时保持代码库的清晰和优雅。
另一方面，如果您的接口臃肿或臃肿，其中包含类不需要的功能的方法，您更有可能违反ISP并在代码中创建耦合，这将导致代码库无法轻松测试。
与其拥有臃肿或臃肿的接口，不如创建两个或更多个薄接口，将方法逻辑地分组，并让您的类实现多个接口，或让接口继承其他薄接口，这种现象被称为多重继承，在C#中得到支持。
以下片段中的IRateCalculator接口违反了ISP。它可以被视为一个污染的接口，因为唯一实现它的类不需要FindLender方法，因为RateCalculator类不需要它：
publicinterfaceIRateCalculator{RateGetYearlyCarLoanRate();RateGetYearlyHouseLoanRate();LenderFindLender(LoanTypeloanType);}RateCalculator类具有GetYearlyCarLoanRate和GetYearlyHouseLoanRate方法，这些方法是必需的以满足类的要求。通过实现IRateCalculator，RateCalculator被迫为FindLender方法实现，而这并不需要：
publicclassRateCalculator:IRateCalculator{publicRateGetYearlyCarLoanRate(){thrownewNotImplementedException();}publicRateGetYearlyHouseLoanRate(){thrownewNotImplementedException();}publicLenderFindLender(LoanTypeloanType){thrownewNotImplementedException();}}前述的IRateCalculator可以重构为两个具有可以逻辑分组在一起的方法的连贯接口。通过小接口，可以以极大的灵活性编写代码，并且易于对实现接口的类进行单元测试：
publicinterfaceIRateCalculator{RateGetYearlyCarLoanRate();RateGetYearlyHouseLonaRate();}publicinterfaceILenderManager{LenderFindLender(LoanTypeloanType);}通过将IRateCalculator重构为两个接口，RateCalculator可以被重构以删除不需要的FindLender方法：
publicclassRateCalculator:IRateCalculator{publicRateGetYearlyCarLoanRate(){thrownewNotImplementedException();}publicRateGetYearlyHouseLonaRate(){thrownewNotImplementedException();}}在实现符合ISP的接口时要注意的反模式是为每个方法创建一个接口，试图创建薄接口；这可能导致创建多个接口，从而导致难以维护的代码库。
刚性或糟糕的设计可能会使软件应用程序的组件或模块的更改变得非常困难，并创建维护问题。这些不灵活的设计通常会破坏先前正常工作的功能。这可能以原则和模式的错误使用、糟糕的代码和不同组件或层的耦合形式出现，从而使维护过程变得非常困难。
当应用程序代码库中存在严格的设计时，仔细检查代码将会发现模块之间紧密耦合，使得更改变得困难。对任何模块的更改可能会导致破坏先前正常工作的另一个模块的风险。观察SOLID原则中的最后一个——依赖反转原则（DIP）可以消除模块之间的任何耦合，使代码库灵活且易于维护。
DIP有两种形式，都旨在实现代码的灵活性和对象及其依赖项之间的松耦合：
当高级模块或实体直接耦合到低级模块时，对低级模块进行更改通常会直接影响高级模块，导致它们发生变化，产生连锁反应。在实际情况下，当对高级模块进行更改时，低级模块应该发生变化。
publicclassAuthenticationManager{privateDbContextdbContext;publicAuthenticationManager(DbContextdbContext){this.dbContext=dbContext;}}在上面的代码片段中，AuthenticationManager类代表了一个高级模块，而传递给类构造函数的DbContextEntityFramework是一个负责CRUD和数据层活动的低级模块。虽然非专业的开发人员可能不会在代码结构中看到任何问题，但它违反了DIP。这是因为AuthenticationManager类依赖于DbContext类，并且对DbContext内部代码进行更改的尝试将会传播到AuthenticationManager，导致它发生变化，从而违反OCP。
我们可以重构AuthenticationManager类，使其具有良好的设计并符合DIP。这将需要创建一个IDbContext接口，并使DbContext实现该接口。
publicinterfaceIDbContext{intSaveChanges();voidDispose();}publicclassDbContext:IDbContext{publicintSaveChanges(){thrownewNotImplementedException();}publicvoidDispose(){thrownewNotImplementedException();}}AuthenticationManager可以根据接口编码，从而打破与DbContext的耦合或直接依赖，并且依赖于抽象。对AuthenticationManager进行编码，使其针对IDbContext意味着接口将被注入到AuthenticationManager的构造函数中，或者使用属性注入：
publicclassAuthenticationManager{privateIDbContextdbContext;publicAuthenticationManager(IDbContextdbContext){this.dbContext=dbContext;}}重构完成后，AuthenticationManager现在使用依赖反转，并依赖于抽象—IDbContext。将来，如果对DbContext类进行更改，将不再影响AuthenticationManager类，并且不会违反OCP。
虽然通过构造函数将IDbContext注入到AutheticationManager中非常优雅，但IDbcontext也可以通过公共属性注入到AuthenticationManager中：
publicclassAuthenticationManager{privateIDbContextdbContext;privateIDbContextDbContext{set{dbContext=value;}}}此外，DI也可以通过接口注入来实现，其中对象引用是使用接口操作传递的。这简单地意味着使用接口来注入依赖项。以下代码片段解释了使用接口注入来实现依赖的概念。
IRateParser是使用ParseRate方法定义创建的。第二个接口IRepository包含InjectRateParser方法，该方法接受IRateParser作为参数，并将注入依赖项。
publicinterfaceIRateParser{RateParseRate();}publicinterfaceIRepository{voidInjectRateParser(IRateParserrateParser);}现在，让我们创建LoanRepository类来实现IRepository接口，并为InjectRateParser创建一个代码实现，以将IRateParser存储库作为依赖项注入到LoanRepository类中以供代码使用：
publicclassLoanRepository:IRepository{IRateParserrateParser;publicvoidInjectRateParser(IRateParserrateParser){this.rateParser=rateParser;}publicfloatGetCheapestRate(LoanTypeloanType){returnrateParser.GetRateByLoanType(loanType);}}接下来，我们可以创建IRateParser依赖的具体实现，XmlRateParser和RestServiceRateParser，它们都包含了从XML和REST源解析贷款利率的ParseRate方法的实现：
publicclassXmlRateParser:IRateParser{publicRateParseRate(){//ParserateavailablefromxmlfilethrownewNotImplementedException();}}publicclassRestServiceRateParser:IRateParser{publicRateParseRate(){//ParserateavailablefromRESTservicethrownewNotImplementedException();}}总之，我们可以使用在前面的代码片段中创建的接口和类来测试接口注入概念。创建了IRateParser的具体对象，它被注入到LoanRepository类中，通过IRepository接口，并且可以使用IRateParser接口的两种实现之一来构造它。
IRateParserrateParser=newXmlRateParser();LoanRepositoryloanRepository=newLoanRepository();((IRepository)loanRepository).InjectRateParser(rateParser);varrate=loanRepository.GetCheapestRate();rateParser=newRestServiceRateParser();((IRepository)loanRepository).InjectRateParser(rateParser);rate=loanRepository.GetCheapestRate();在本节中描述的任何三种技术都可以有效地用于在需要时将依赖项注入到代码中。适当有效地使用DIP可以促进创建易于维护的松散耦合的应用程序。
ASP.NETCore的核心是DI。该框架提供了内置的DI服务，允许开发人员创建松散耦合的应用程序，并防止依赖关系的实例化或构造。使用内置的DI服务，您的应用程序代码可以设置为使用DI，并且依赖项可以被注入到Startup类中的方法中。虽然默认的DI容器具有一些很酷的功能，但您仍然可以在ASP.NETCore应用程序中使用其他已知的成熟的DI容器。
您可以将代码配置为以两种模式使用DI：
DI容器，也称为控制反转（IoC）容器，通常是一个可以创建具有其关联依赖项的类的类或工厂。在成功构造具有注入依赖项的类之前，项目必须设计或设置为使用DI，并且DI容器必须已配置为具有依赖类型。实质上，DI将具有包含接口到其具体类的映射的配置，并将使用此配置来解析所需依赖项的类。
ASP.NETCore内置的IoC容器由IServiceProvider接口表示，您可以使用Startup类中的ConfigureService方法对其进行配置。容器默认支持构造函数注入。在ConfigureService方法中，可以定义服务和平台功能，例如EntityFrameworkCore和ASP.NETMVCCore：
publicvoidConfigureServices(IServiceCollectionservices){//Addframeworkservices.services.AddDbContext
用于配置服务的其他扩展方法是AddScoped和AddSingleton方法。AddScoped每次请求只创建一次服务：
services.AddScoped
//instantiatingsingletonservices.AddSingleton
使用DI将简化应用程序开发体验，并使您能够编写松散耦合且易于测试的代码。在典型的ASP.NETCoreMVC应用程序中，您应该使用DI来处理依赖项，例如存储库、控制器、适配器和服务，并避免对服务或HttpContext进行静态访问。
本章中使用的面向对象设计原则将帮助您掌握编写清晰、灵活、易于维护和易于测试代码所需的技能。本章中解释的LoD和SOLID原则可以作为创建松散耦合的面向对象软件应用程序的指导原则。
为了获得TDD周期的好处，您必须编写可测试的代码。所涵盖的SOLID原则描述了适当的实践，可以促进编写可轻松维护并在需要时进行增强的可测试代码。本章的最后一节着重介绍了为ASP.NETCoreMVC应用程序设置和使用依赖注入容器。
在下一章中，我们将讨论良好单元测试的属性，.NET生态系统中可用于创建测试的单元测试框架，以及在单元测试ASP.NETMVCCore项目时需要考虑的内容，我们还将深入探讨在.NETCore平台上使用xUnit库进行单元测试的属性。
通过单元测试，开发人员能够快速识别代码中的错误，从而增加开发团队对正在发布的软件产品质量的信心。单元测试主要由程序员和测试人员进行，这项活动涉及将应用程序的要求和功能分解为可以单独测试的单元。
单元测试旨在保持小型并经常运行，特别是在对代码进行更改时，以确保代码库中的工作功能不会出现故障。在进行TDD时，必须在编写要测试的代码之前编写单元测试。测试通常用作设计和编写代码的辅助工具，并且有效地是代码设计和规范的文档。
在本章中，我们将解释如何创建基本单元测试，并使用xUnit断言证明我们的单元测试结果。本章将涵盖以下主题：
单元测试是编写用于测试另一段代码的代码。有时它被称为最低级别的测试，因为它用于测试应用程序的最低级别的代码。单元测试调用要测试的方法或类来验证和断言有关被测试代码的逻辑、功能和行为的假设。
单元测试的主要目的是验证被测试代码单元，以确保代码片段执行其设计用途而不是其他用途。通过单元测试，可以证明代码单元的正确性，只有当单元测试编写得好时才能实现。虽然单元测试将证明正确性并有助于发现代码中的错误，但如果被测试的代码设计和编写不佳，代码质量可能不会得到改善。
当您正确编写单元测试时，您可以在一定程度上确信您的应用程序在发布时会正确运行。通过测试套件获得的测试覆盖率，您可以获得有关代码库中方法、类和其他对象的测试写入频率的指标，并且您将获得有关测试运行频率以及测试通过或失败次数的有意义信息。
单元测试的这一特性不容忽视。与被测试的代码类似，单元测试应该易于阅读和理解。编码标准和原则也适用于测试。应该避免使用魔术数字或常量等反模式，因为它们会使测试混乱并且难以阅读。在下面的测试中，整数10是一个魔术数字，因为它直接使用。这影响了测试的可读性和清晰度：
[Fact]publicvoidTest_CheckPasswordLength_ShouldReturnTrue(){stringpassword="civic";boolisValid=false;if(password.Length>=10)isValid=true;Assert.True(isValid);}有一个良好的测试结构模式可以采用，它被广泛称为三A模式或3A模式——安排，行动和断言——它将测试设置与验证分开。您需要确保测试所需的数据被安排好，然后是对被测试方法进行操作的代码行，最后断言被测试方法的结果是否符合预期：
单元测试基本上应该是一个单元，它应该被设计和编写成可以独立运行的形式。在这种情况下，被测试的单元，即一个方法，应该已经被编写成微妙地依赖于其他方法。如果可能的话，方法所需的数据应该通过方法参数传递，或者应该在单元内提供，它不应该需要外部请求或设置数据来进行功能。
单元测试不应该依赖于或受到任何其他测试的影响。当单元测试相互依赖时，如果其中一个测试在运行时失败，所有其他依赖测试也会失败。代码所需的所有数据应该由单元测试提供。
[Fact]publicvoidTest_DeleteLoan_ShouldReturnNull(){loanRepository.ArchiveLoan(12);loanRepository.DeleteLoan(12);varloan=loanRepository.GetById(12);Assert.Null(loan);}此片段中测试的问题在于同时发生了很多事情。如果测试失败，没有特定的方法来检查哪个方法调用导致了失败。为了清晰和易于维护，这个测试可以分解成不同的测试。
单元测试应该易于运行，而无需每次运行时都进行修改。实质上，测试应该准备好重复运行而无需修改。在下面的测试中，Test_DeleteLoan_ShouldReturnNull测试方法是不可重复的，因为每次运行测试都必须进行修改。为了避免这种情况，最好模拟loanRepository对象：
[Fact]publicvoidTest_DeleteLoan_ShouldReturnNull(){loanRepository.DeleteLoan(12);varloan=loanRepository.GetLoanById(12);Assert.Null(loan);}易维护且运行速度快单元测试应该以一种允许它们快速运行的方式编写。测试应该易于实现，任何开发团队的成员都应该能够运行它。因为软件应用是动态的，不断发展的，所以代码库的测试应该易于维护，因为被测试的底层代码发生变化。为了使测试运行更快，尽量减少依赖关系。
很多时候，大多数程序员在单元测试方面做错了，他们编写具有固有依赖关系的单元测试，这反过来使得测试运行变得更慢。一个快速的经验法则可以给你一个线索，表明你在单元测试中做错了什么，那就是测试运行得非常慢。此外，当你的单元测试调用后端服务器或执行一些繁琐的I/O操作时，这表明存在测试问题。
单元测试应该易于设置，并且与任何直接或外部依赖项解耦。应使用适当的模拟框架对外部依赖项进行模拟。适当的对象设置应在设置方法或测试类构造函数中完成。
最后，良好的单元测试应该具有良好的代码覆盖率。测试方法中的所有执行路径都应该被覆盖，所有测试都应该有定义的可测试标准。
.NETCore开发平台已经被设计为完全支持测试。这可以归因于采用的架构。这使得在.NETCore平台上进行TDD相对容易且值得。
在.NET和.NETCore中有几个可用的单元测试框架。这些框架基本上提供了从您喜欢的IDE、代码编辑器、专用测试运行器，或者有时通过命令行直接编写和执行单元测试的简单和灵活的方式。
.NET平台上存在着蓬勃发展的测试框架和套件生态系统。这些框架包含各种适配器，可用于创建单元测试项目以及用于持续集成和部署。
这个框架生态系统已经被.NETCore平台继承。这使得在.NETCore上实践TDD非常容易。VisualStudioIDE是开放且广泛的，可以更快、更容易地从NuGet安装测试插件和适配器，用于测试项目。
有许多免费和开源的测试框架，用于各种类型的测试。最流行的框架是MSTest、NUnit和xUnit.net。
MicrosoftMSTest是随VisualStudio一起提供的默认测试框架，由微软开发，最初是.NET框架的一部分，但也包含在.NETCore中。MSTest框架用于编写负载、功能、UI和单元测试。
MSTest可以作为统一的应用程序平台支持，也可以用于测试各种应用程序——桌面、商店、通用Windows平台（UWP）和ASP.NETCore。MSTest作为NuGet软件包提供。
基于MSTest的单元测试项目可以添加到包含要测试的项目的现有解决方案中，按照在VisualStudio2017中向解决方案添加新项目的步骤进行操作：
或者，在创建新项目或向现有解决方案添加新项目时，选择“类库（.NETCore）”选项，并从NuGet添加对MSTest的引用。从NuGet安装以下软件包到类库项目中，使用NuGet软件包管理器控制台或GUI选项。您可以从NuGet软件包管理器控制台运行以下命令：
Install-PackageMSTest.TestFrameworkInstall-Packagedotnet-test-mstest无论使用哪种方法创建MSTest测试项目，VisualStudio都会自动创建一个UnitTest1或Class1.cs文件。您可以重命名类或删除它以创建一个新的测试类，该类将使用MSTest的TestClass属性进行修饰，表示该类将包含测试方法。
实际的测试方法将使用TestMethod属性进行修饰，将它们标记为测试，这将使得MSTest测试运行器可以运行这些测试。MSTest有丰富的Assert辅助类集合，可用于验证单元测试的期望结果：
usingMicrosoft.VisualStudio.TestTools.UnitTesting;usingLoanApplication.Core.Repository;namespaceMsTest{[TestClass]publicclassLoanRepositoryTest{privateLoanRepositoryloanRepository;publicLoanRepositoryTest(){loanRepository=newLoanRepository();}[TestMethod]publicvoidTest_GetLoanById_ShouldReturnLoan(){varloan=loanRepository.GetLoanById(12);Assert.IsNotNull(loan);}}}您可以从VisualStudio2017的测试资源管理器窗口中运行Test_GetLoanById_ShouldReturnLoan测试方法。可以从测试菜单中打开此窗口，选择窗口，然后选择测试资源管理器。右键单击测试并选择运行选定的测试：
您还可以从控制台运行测试。打开命令提示窗口并将目录更改为包含测试项目的文件夹，或者如果要运行解决方案中的所有测试项目，则更改为解决方案文件夹。运行dotnettest命令。项目将被构建，同时可用的测试将被发现和执行：
NUnit是一个最初从Java的JUnit移植的测试框架，可用于测试.NET平台上所有编程语言编写的项目。目前是第3版，其开源测试框架是在MIT许可下发布的。
NUnit测试框架包括引擎和控制台运行器。此外，它还有用于测试在移动设备上运行的应用程序的测试运行器—XamarinRunners。NUnit测试适配器和生成器基本上可以使使用VisualStudioIDE进行测试变得无缝和相对容易。
使用NUnit测试.NETCore或.NET标准应用程序需要使用VisualStudio测试适配器的NUnit3版本。需要安装NUnit测试项目模板，以便能够创建NUnit测试项目，通常只需要进行一次。
NUnit适配器可以通过以下步骤安装到VisualStudio2017中：
这将下载适配器并将其安装为VisualStudio2017的模板，您必须重新启动VisualStudio才能生效：
或者，您可以每次要创建测试项目时直接从NuGet安装NUnit3测试适配器。
要将NUnit测试项目添加到现有解决方案中，请按照以下步骤操作：
项目设置完成后，可以编写和运行单元测试。与MSTest类似，NUnit也有用于设置测试方法和测试类的属性。
TestFixture属性用于标记一个类作为测试方法的容器。Test属性用于修饰测试方法，并使这些方法可以从NUnit测试运行器中调用。
NUnit还有其他用于一些设置和测试目的的属性。OneTimeSetup属性用于修饰一个方法，该方法仅在运行所有子测试之前调用一次。类似的属性是SetUp，用于修饰在运行每个测试之前调用的方法：
usingLoanApplication.Core.Repository;usingNUnit;usingNUnit.Framework;namespaceMsTest{[TestFixture]publicclassLoanRepositoryTest{privateLoanRepositoryloanRepository;[OneTimeSetUp]publicvoidSetupTest(){loanRepository=newLoanRepository();}[Test]publicvoidTest_GetLoanById_ShouldReturnLoan(){varloan=loanRepository.GetLoanById(12);Assert.IsNotNull(loan);}}}测试可以从“测试资源管理器”窗口运行，类似于在MSTest测试项目中运行的方式。此外，可以使用dotnettest从命令行运行测试。但是，您必须将Microsoft.NET.Test.SdkVersion15.5.0添加为NUnit测试项目的引用：
xUnit.net是用于测试使用F＃，VB.NET，C＃和其他符合.NET的编程语言编写的项目的.NET平台的开源单元测试框架。xUnit.net是由NUnit的第2版的发明者编写的，并根据Apache2许可证获得许可。
xUnit.net可用于测试传统的.NET平台应用程序，包括控制台和ASP.NET应用程序，UWP应用程序，移动设备应用程序以及包括ASP.NETCore的.NETCore应用程序。
与NUnit或MSTest不同，测试类分别使用TestFixture和TestClass属性进行装饰，xUnit.net测试类不需要属性装饰。该框架会自动检测测试项目或程序集中所有公共类中的所有测试方法。
此外，在xUnit.net中不提供测试设置和拆卸属性，可以使用无参数构造函数来设置测试对象或模拟依赖项。测试类可以实现IDisposable接口，并在Dispose方法中清理对象或依赖项：
publicclassTestClass:IDisposable{publicTestClass(){//dotestclassdependenciesandobjectsetup}publicvoidDispose(){//docleanuphere}}xUnit.net支持两种主要类型的测试-事实和理论。事实是始终为真的测试；它们是没有参数的测试。理论是只有在传递特定数据集时才为真的测试；它们本质上是参数化测试。分别使用[Fact]和[Theory]属性来装饰事实和理论测试：
[Fact]publicvoidTestMethod1(){Assert.Equal(8,(4*2));}[Theory][InlineData("name")][InlineData("word")]publicvoidTestMethod2(stringvalue){Assert.Equal(4,value.Length);}[InlineData]属性用于在TestMethod2中装饰理论测试，以向测试方法提供测试数据，以在测试执行期间使用。
xUnit.net的配置有两种类型。xUnit.net允许配置文件为基于JSON或XML。必须为要测试的每个程序集进行xUnit.net配置。用于xUnit.net的配置文件取决于被测试应用程序的开发平台，尽管JSON配置文件可用于所有平台。
要使用JSON配置文件，在VisualStudio2017中创建测试项目后，应向测试项目的根文件夹添加一个新的JSON文件，并将其命名为xunit.runner.json：
将文件添加到项目后，必须指示VisualStudio将.json文件复制到项目的输出文件夹中，以便xUnit测试运行程序找到它。为此，应按照以下步骤操作：
这将确保在更改时配置文件始终被复制到输出文件夹。xUnit中支持的配置元素放置在配置文件中的顶级JSON对象中，如此处所见：
{"appDomain":"ifAvailable","methodDisplay":"classAndMethod","diagnosticMessages":false,"internalDiagnosticMessages":false,"maxParallelThreads":8}使用支持JSON的VisualStudio版本时，它将根据配置文件名称自动检测模式。此外，在编辑xunit.runner.json文件时，VisualStudioIntelliSense中将提供上下文帮助。此表中解释了各种配置元素及其可接受的值：
xUnit.net用于桌面和PCL测试项目的另一个配置文件选项是XML配置。如果测试项目尚未具有App.Config文件，则应将其添加到测试项目中。
在App.Config文件的appSettings部分下，您可以添加配置元素及其值。在使用XML配置文件时，必须在前面表中解释的配置元素后面添加xUnit。例如，JSON配置文件中的appDomain元素将写为xunit.appDomain：
测试框架是实现测试发现和执行的代码。测试框架将发现的测试链接到xunit.core.dll和xunit.execution.dll库。这些库与单元测试一起存在。xunit.abstractions.dll是xUnit.net的另一个有用的库，其中包含测试运行器和测试框架在通信中使用的抽象。
测试并行化是在xUnit.net的2.0版本中引入的。这个功能允许开发人员并行运行多个测试。测试并行化是必要的，因为大型代码库通常有数千个测试运行，需要多次运行。
这些代码库有大量的测试，因为需要确保功能代码的工作正常且没有问题。它们还利用了现在可用的超快计算资源来运行并行测试，这要归功于计算机硬件技术的进步。
您可以编写使用并行化的测试，并利用计算机上可用的核心，从而使测试运行更快，或者让xUnit.net并行运行多个测试。通常情况下，后者更受欢迎，这可以确保测试以计算机运行它们的速度运行。在xUnit.net中，测试并行可以在框架级别进行，其中框架支持在同一程序集中并行运行多个测试，或者在测试运行器中进行并行化，其中运行器可以并行运行多个测试程序集。
测试是使用测试集合并行运行的。每个测试类都是一个测试集合，测试集合内的测试不会相互并行运行。例如，如果运行LoanCalculatorTest中的测试，测试运行器将按顺序运行类中的两个测试，因为它们属于同一个测试集合：
publicclassLoanCalculatorTest{[Fact]publicvoidTestCalculateLoan(){Assert.Equal(16,(4*4));}[Fact]publicvoidTestCalculateRate(){Assert.Equal(12,(4*3));}}不同的测试类中的测试可以并行运行，因为它们属于不同的测试集合。让我们修改LoanCalculatorTest，将TestCalculateRate测试方法放入一个单独的测试类RateCalculatorTest中：
不同的测试类中的测试可以配置为不并行运行。这可以通过使用相同名称的Collection属性对类进行装饰来实现。如果将Collection属性添加到LoanCalculatorTest和RateCalculatorTest中：
[Collection("Donotruninparallel")]publicclassLoanCalculatorTest{[Fact]publicvoidTestCalculateLoan(){Assert.Equal(16,(4*4));}}[Collection("Donotruninparallel")]publicclassRateCalculatorTest{[Fact]publicvoidTestCalculateRate(){Assert.Equal(12,(4*3));}}LoanCalculatorTest和RateCalculatorTest类中的测试不会并行运行，因为这些类基于属性装饰属于同一个测试集合。
MVC模式提供了清晰的演示逻辑和业务逻辑之间的分离，易于扩展和维护。它最初是为桌面应用程序设计的，但后来在Web应用程序中得到了广泛的使用和流行。
ASP.NETCoreMVC项目可以以与测试其他类型的.NETCore项目相同的方式进行测试。ASP.NETCore支持对控制器类、razor页面、页面模型、业务逻辑和应用程序数据访问层进行单元测试。为了构建健壮的MVC应用程序，各种应用程序组件必须在隔离环境中进行测试，并在集成后进行测试。
ASP.NETCoreMVC控制器类处理用户交互，这转化为浏览器上的请求。控制器获取适当的模型并选择要呈现的视图，以显示用户界面。控制器从视图中读取用户的输入数据、事件和交互，并将其传递给模型。控制器验证来自视图的输入，然后执行修改数据模型状态的业务操作。
Controller类应该轻量级，并包含渲染视图所需的最小逻辑，以便进行简单的测试和维护。控制器应该验证模型的状态并确定有效性，调用执行业务逻辑验证和管理数据持久性的适当代码，然后向用户显示适当的视图。
在对Controller类进行单元测试时，主要目的是在隔离环境中测试控制器动作方法的行为，这应该在不混淆测试与其他重要的MVC构造（如模型绑定、路由、过滤器和其他自定义控制器实用对象）的情况下进行。这些其他构造（如果是自定义编写的）应该以不同的方式进行单元测试，并在集成测试中与控制器一起进行整体测试。
审查LoanApplication项目的HomeController类，Controller类包含在VisualStudio中创建项目时添加的四个动作方法：
usingSystem;usingSystem.Collections.Generic;usingSystem.Diagnostics;usingSystem.Linq;usingSystem.Threading.Tasks;usingMicrosoft.AspNetCore.Mvc;usingLoanApplication.Models;namespaceLoanApplication.Controllers{publicclassHomeController:Controller{publicIActionResultIndex(){returnView();}publicIActionResultAbout(){ViewData["Message"]="Yourapplicationdescriptionpage.";returnView();}}}HomeController类当前包含具有返回视图的基本逻辑的动作方法。为了对MVC项目进行单元测试，应向解决方案添加一个新的xUnit.net测试项目，以便将测试与实际项目代码分开。将HomeControllerTest测试类添加到新创建的测试项目中。
将要编写的测试方法将验证HomeController类的Index和About动作方法返回的viewResult对象：
usingSystem;usingSystem.Collections.Generic;usingSystem.Linq;usingSystem.Threading.Tasks;usingMicrosoft.AspNetCore.Mvc;usingLoanApplication.Controllers;usingXunit;namespaceLoanApplication.Tests.Unit.Controller{publicclassHomeControllerTest{[Fact]publicvoidTestIndex(){varhomeController=newHomeController();varresult=homeController.Index();varviewResult=Assert.IsType
publicclassHomeController:Controller{privateILoanRepositoryloanRepository;publicHomeController(ILoanRepositoryloanRepository){this.loanRepository=loanRepository;}publicIActionResultIndex(){varloanTypes=loanRepository.GetLoanTypes();ViewData["LoanTypes"]=loanTypes;returnView();}}ILoanRepository通过类构造函数注入到HomeController中，在测试类中，ILoanRepository将使用Moq框架进行模拟。在TestIndex测试方法中，使用LoanType列表设置了HomeController类中Index方法所需的模拟对象：
publicclassHomeControllerTest{privateMock
Razor页面使得在页面上编写功能相对容易。Razor页面类似于Razor视图，但增加了@page指令。@page指令必须是页面中的第一个指令，它会自动将文件转换为MVC操作，处理请求而无需经过控制器。
在ASP.NETCore中，可以测试Razor页面，以确保它们在隔离和集成应用程序中正常工作。Razor页面测试可以涉及测试数据访问层代码、页面组件和页面模型。
以下代码片段显示了一个单元测试，用于验证页面模型是否正确重定向：
测试用例是包含测试方法的测试类。通常，每个被测试类都有一个测试类。开发人员在测试中构建测试的另一种常见做法是为每个被测试的方法创建一个嵌套类，或者为被测试的类创建一个基类测试类，为每个被测试的方法创建一个子类。此外，还有每个功能一个测试类的方法，其中所有共同验证应用程序功能的测试方法都分组在一个测试用例中。
这些测试结构方法促进了DRY原则，并在编写测试时实现了代码的可重用性。没有一种方法适用于所有目的，选择特定的方法应该基于应用程序开发周围的情况，并在与团队成员进行有效沟通后进行。
publicclassHomeControllerTest{privateMock
publicclassIndexMethod:HomeControllerTest{[Fact]publicvoidTestIndex(){varresult=homeController.Index();varviewResult=Assert.IsType
[Fact]publicvoidTestAbout_ShouldReturnViewResult(){varresult=homeController.About();varviewResult=Assert.IsType
往往，单元测试类希望共享测试上下文，因为创建和清理测试上下文可能很昂贵。xUnit提供了三种方法来实现这一点：
当您希望每个测试类中的每个测试都有一个新的测试上下文时，您应该使用构造函数和dispose。在下面的代码中，上下文对象将为LoanModuleTest类中的每个测试方法构造和处理：
publicclassLoanModuleTest:IDisposable{publicLoanAppContextContext{get;privateset;}publicLoanModuleTest(){Context=newLoanAppContext();}publicvoidDispose(){Context=null;}[Fact]publicvoidTestSaveLoan_ShouldReturnTrue(){Loanloan=newLoan{Description="CarLoan"};Context.Loan.Add(loan);varisSaved=Context.Save();Assert.True(isSaved);}}当您打算创建将在类中的所有测试之间共享的测试上下文，并在所有测试运行完成后进行清理时，可以使用类装置方法。要使用类装置，您必须创建一个具有包含要共享的对象代码的构造函数的装置类。测试类应该实现IClassFixture<>，并且您应该将装置类作为测试类的构造函数参数添加：
publicclassEFCoreFixture:IDisposable{publicLoanAppContextContext{get;privateset;}publicEFCoreFixture(){Context=newLoanAppContext();}publicvoidDispose(){Context=null;}}以下片段中的LoanModuleTest类实现了IClassFixture，并将EFCoreFixture作为参数传递。EFCoreFixture被注入到测试类构造函数中：
publicclassLoanModuleTest:IClassFixture
使用集合装置：
VisualStudio2017企业版目前支持NUnit、MSTest和xUnit的实时单元测试。可以从工具菜单配置实时单元测试——从顶级菜单选择选项，并在选项对话框的左窗格中选择实时单元测试。可以从选项对话框调整可用的实时单元测试配置选项：
可以通过选择实时单元测试并选择开始来从测试菜单启用实时单元测试：
启用实时单元测试后，实时单元测试菜单上的其他可用选项将显示。除了开始，还将有暂停、停止和重置清理。菜单功能在此处描述：
在下面的屏幕截图中，可以在启用实时单元测试时看到覆盖可视化。每行代码都会更新并用绿色、红色和蓝色装饰，以指示该行代码是由通过的测试、失败的测试覆盖还是未被任何测试覆盖的：
xUnit.net断言验证测试方法的行为。断言验证了预期结果应为真的条件。当断言失败时，当前测试的执行将终止，并抛出异常。以下表格解释了xUnit.net中可用的断言：
以下代码片段使用了前面表格中描述的一些xUnit.net断言方法。Assertions单元测试方法展示了在xUnit.net中进行单元测试时如何使用断言方法来验证方法的行为：
[Fact]publicvoidAssertions(){Assert.Equal(8,(4*2));Assert.NotEqual(6,(4*2));List
ReSharper是JetBrains开发的.NET开发人员的VisualStudio扩展。它的测试运行器是.NET平台上可用的测试运行器中最受欢迎的，ReSharper生产工具提供了增强程序员生产力的其他功能。它有一个单元测试运行器，可以帮助您基于xUnit.net、NUnit、MSTest和其他几个测试框架运行和调试单元测试。
ReShaper可以检测到.NET和.NETCore平台上使用的测试框架编写的测试。ReSharper在编辑器中添加图标，可以单击以调试或运行测试：
ReSharper使用UnitTestSessions窗口运行单元测试。ReSharper的单元测试会话窗口允许您并行运行任意数量的单元测试会话，彼此独立。但是在调试模式下只能运行一个会话。
您可以使用单元测试树来过滤测试，这样可以获得测试的结构。它显示了哪些测试失败、通过或尚未运行。此外，通过双击测试，您可以直接导航到源代码：
在本章中，讨论了良好单元测试的属性。我们还广泛讨论了使用xUnit.net框架中可用的测试功能的单元测试程序。解释了VisualStudio2017中的实时单元测试功能，并使用xUnit.net的Fact属性，使用断言来创建基本的单元测试。
在上一章中，我们讨论了良好单元测试的属性，以及xUnit.net支持的两种测试类型Fact和Theory。此外，我们还通过xUnit.net单元测试框架中可用的丰富测试断言集合创建了单元测试。
为软件项目编写的单元测试应该从开发阶段开始反复运行，在部署期间，维护期间，以及在项目的整个生命周期中都应该有效地运行。通常情况下，这些测试应该在不同的数据输入上运行相同的执行步骤，而测试和被测试的代码都应该在不同的数据输入下表现出一致的行为。
通过使用不同的数据集运行测试可以通过创建或复制具有相似步骤的现有测试来实现。这种方法的问题在于维护，因为必须在各种复制的测试中影响测试逻辑的更改。xUnit.net通过其数据驱动单元测试功能解决了这一挑战，称为theories，它允许在不同的测试数据集上运行测试。
在第四章中解释的示例数据驱动单元测试使用了内联方法。还有其他属性可以用于向测试提供数据，如MemberData和ClassData。
在本章中，我们将通过使用xUnit.net框架创建数据驱动单元测试，并涵盖以下主题：
数据驱动单元测试是一个概念，因为它能够使用不同的数据集执行测试，所以它能够对代码行为提供深入的见解。通过数据驱动单元测试获得的见解可以帮助我们对应用程序开发方法做出明智的决策，并且可以识别出需要改进的潜在领域。可以从数据单元测试的报告和代码覆盖率中制定策略，这些策略可以后来用于重构具有潜在性能问题和应用程序逻辑中的错误的代码。
数据驱动单元测试的一些好处在以下部分进行了解释。
通过数据驱动测试，可以更容易地减少冗余，同时保持全面的测试覆盖。这是因为可以避免测试代码的重复。传统上需要为不同数据集重复测试的测试现在可以用于不同的数据集。当存在具有相似结构但具有不同数据的测试时，这表明可以将这些测试重构为数据驱动测试。
让我们在以下片段中回顾CarLoanCalculator类和相应的LoanCalculatorTest测试类。与传统的编写测试方法相比，这将为我们提供宝贵的见解，说明为什么数据驱动测试可以简化测试，同时在编写代码时提供简洁性。
publicclassCarLoanCalculator:LoanCalculator{publicCarLoanCalculator(RateParserrateParser){base.rateParser=rateParser;}publicoverrideLoanCalculateLoan(LoanDTOloanDTO){Loanloan=newLoan();loan.LoanType=loanDTO.LoanType;loan.InterestRate=rateParser.GetRateByLoanType(loanDTO.LoanType,loanDTO.LocationType,loanDTO.JobType);//dootherprocessingreturnloan}}为了验证CarLoanCalculator类的一致行为，将使用以下测试场景验证CalculateLoan方法返回的Loan对象，当方法参数LoanDTO具有不同的LoanType、LocationType和JobType组合时。CarLoanCalculatorTest类中的Test_CalculateLoan_ShouldReturnLoan测试方法验证了描述的每个场景：
当业务人员和质量保证测试人员参与自动化测试过程时，可以改善软件应用程序的质量。他们可以使用数据文件作为数据源，无需太多的技术知识，就可以向数据源中填充执行测试所需的数据。可以使用不同的数据集多次运行测试，以彻底测试代码，以确保其健壮性。
使用数据驱动测试，您可以清晰地分离测试和数据。原本可能会与数据混在一起的测试现在将使用适当的逻辑进行分离。这确保了数据源可以在不更改使用它们的测试的情况下进行修改。
通过数据驱动单元测试，应用程序的整体质量得到改善，因为您可以使用各种数据集获得良好的覆盖率，并具有用于微调和优化正在开发的应用程序以获得改进性能的指标。
在xUnit.net中，数据驱动测试被称为理论。它们是使用Theory属性装饰的测试。当测试方法使用Theory属性装饰时，必须另外使用数据属性装饰，测试运行器将使用该属性确定要在执行测试时使用的数据源：
[Theory]publicvoidTest_CalculateRates_ShouldReturnRate(){//testnotimplementedyet}当测试标记为数据理论时，从数据源中提供的数据直接映射到测试方法的参数。与使用Fact属性装饰的常规测试不同，数据理论的执行次数基于从数据源获取的可用数据行数。
至少需要传递一个数据属性作为测试方法参数，以便xUnit.net将测试视为数据驱动并成功执行。要传递给测试的数据属性可以是InlineData、MemberData和ClassData中的任何一个。这些数据属性源自Xunit.sdk.DataAttribute。
内联数据驱动测试是使用xUnit.net框架编写数据驱动测试的最基本或最简单的方式。内联数据驱动测试使用InlineData属性编写，该属性用于装饰测试方法，除了Theory属性之外：
[Theory,InlineData("arguments")]当测试方法需要简单的参数并且不接受类实例化作为InlineData参数时，可以使用内联数据驱动测试。使用内联数据驱动测试的主要缺点是缺乏灵活性。不能将内联数据与另一个测试重复使用。
当在数据理论中使用InlineData属性时，数据行是硬编码的，并内联传递到测试方法中。要用于测试的所需数据可以是任何数据类型，并作为参数传递到InlineData属性中：
publicclassTheoryTest{[Theory,InlineData("name")]publicvoidTestCheckWordLength_ShouldReturnBoolean(stringword){Assert.Equal(4,word.Length);}}内联数据驱动测试可以有多个InlineData属性，指定测试方法的参数。多个InlineData数据理论的语法在以下代码中指定：
[Theory,InlineData("argument1"),InlineData("argument2"),InlineData("argumentn")]TestCheckWordLength_ShouldReturnBoolean方法可以更改为具有三个内联数据行，并且可以根据需要添加更多数据行到测试中。为了保持测试的清晰，建议每个测试不要超过必要或所需的内联数据：
publicclassTheoryTest{[Theory,InlineData("name"),InlineData("word"),InlineData("city")]publicvoidTestCheckWordLength_ShouldReturnBoolean(stringword){Assert.Equal(4,word.Length);}}在编写内联数据驱动单元测试时，必须确保测试方法中的参数数量与传递给InlineData属性的数据行中的参数数量匹配；否则，xUnit测试运行器将抛出System.InvalidOperationException。以下代码片段中TestCheckWordLength_ShouldReturnBoolean方法中的InlineData属性已被修改为接受两个参数：
publicclassTheoryTest{[Theory,InlineData("word","name")]publicvoidTestCheckWordLength_ShouldReturnBoolean(stringword){Assert.Equal(4,word.Length);}}当您在前面的代码片段中运行数据理论测试时，xUnit测试运行器会因为传递了两个参数"word"和"name"给InlineData属性，而不是预期的一个参数，导致测试失败并显示InvalidOperationException，如下面的屏幕截图所示：
当运行内联数据驱动测试时，xUnit.net将根据添加到测试方法的InlineData属性或数据行的数量创建测试的数量。在以下代码片段中，xUnit.net将创建两个测试，一个用于InlineData属性的参数"name"，另一个用于参数"city"：
[Theory,InlineData("name"),InlineData("city")]publicvoidTestCheckWordLength_ShouldReturnBoolean(stringword){Assert.Equal(4,word.Length);}如果您在VisualStudio中使用测试运行器运行TestCheckWordLength_ShouldReturnBoolean测试方法，测试应该成功运行并通过。基于属性创建的两个测试可以通过从InlineData属性传递给它们的参数来区分：
现在，让我们修改数据驱动单元测试的好处部分中的Test_CalculateLoan_ShouldReturnCorrectRate测试方法，使用InlineData来加载测试数据，而不是直接在测试方法的代码中硬编码测试数据：
[Theory,InlineData(newLoanDTO{LoanType=LoanType.CarLoan,JobType=JobType.Professional,LocationType=LocationType.Location1})]publicvoidTest_CalculateLoan_ShouldReturnCorrectRate(LoanDTOloanDTO){Loanloan=carLoanCalculator.CalculateLoan(loanDTO);Assert.NotNull(loan);Assert.Equal(8,loan.InterestRate);}在VisualStudio中，上述代码片段将导致语法错误，IntelliSense上下文菜单显示错误——属性参数必须是常量表达式、表达式类型或属性参数类型的数组创建表达式：
在InlineData属性中使用属性或自定义类型作为参数类型是不允许的，这表明LoanDTO类的新实例不能作为InlineData属性的参数。这是InlineData属性的限制，因为它不能用于从属性、类、方法或自定义类型加载数据。
在编写内联数据驱动测试时遇到的灵活性不足可以通过使用属性数据驱动测试来克服。属性数据驱动单元测试是通过使用MemberData和ClassData属性在xUnit.net中编写的。使用这两个属性，可以创建从不同数据源（如文件或数据库）加载数据的数据理论。
当要创建并加载来自以下数据源的数据行的数据理论时，使用MemberData属性：
在使用MemberData时，数据源必须返回与IEnumerable
Test_CalculateLoan_ShouldReturnCorrectRate测试方法在数据驱动单元测试的好处部分中，可以重构以使用MemberData属性来加载测试的数据。创建一个静态的IEnumerable方法GetLoanDTOs，使用yield语句返回一个LoanDTO对象给测试方法：
publicstaticIEnumerable
[Theory,MemberData("GetLoanDTOs")]publicvoidTest_CalculateLoan_ShouldReturnCorrectRate(LoanDTOloanDTO){Loanloan=carLoanCalculator.CalculateLoan(loanDTO);Assert.NotNull(loan);Assert.InRange(loan.InterestRate,8,12);}另外，数据源名称可以通过nameof表达式传递给MemeberData属性，nameof是C#关键字，用于获取变量、类型或成员的字符串名称。语法是MemberData(nameof(methodName))：
[Theory,MemberData(nameof(GetLoanDTOs))]publicvoidTest_CalculateLoan_ShouldReturnCorrectRate(LoanDTOloanDTO){Loanloan=carLoanCalculator.CalculateLoan(loanDTO);Assert.NotNull(loan);Assert.InRange(loan.InterestRate,8,12);}与MemberData属性一起使用静态方法类似，静态字段和属性可以用于提供数据理论的数据集。
Test_CalculateLoan_ShouldReturnCorrectRate可以重构以使用静态属性代替方法：
[Theory,MemberData("LoanDTOs")]publicvoidTest_CalculateLoan_ShouldReturnCorrectRate(LoanDTOloanDTO){Loanloan=carLoanCalculator.CalculateLoan(loanDTO);Assert.NotNull(loan);Assert.InRange(loan.InterestRate,8,12);}创建一个静态属性LoanDTOs，返回IEnumerable
publicstaticIEnumerable
遵循上述方法要求静态方法、字段或属性用于加载测试数据的位置与数据理论相同。为了使测试组织良好，有时需要将测试方法与用于加载数据的静态方法或属性分开放在不同的类中：
publicclassDataClass{publicstaticIEnumerable
[Theory,MemberData(nameof(LoanDTOs),MemberType=typeof(DataClass))]publicvoidTest_CalculateLoan_ShouldReturnCorrectRate(LoanDTOloanDTO){Loanloan=carLoanCalculator.CalculateLoan(loanDTO);Assert.NotNull(loan);Assert.InRange(loan.InterestRate,8,12);}在使用静态方法时，该方法也可以有一个参数，当处理数据时可能需要使用该参数。例如，可以将整数值传递给方法，以指定要返回的记录数。该参数可以直接从MemberData属性传递给静态方法：
[Theory,MemberData(nameof(GetLoanDTOs),parameters:1,MemberType=typeof(DataClass))]publicvoidTest_CalculateLoan_ShouldReturnCorrectRate3(LoanDTOloanDTO){Loanloan=carLoanCalculator.CalculateLoan(loanDTO);Assert.NotNull(loan);Assert.InRange(loan.InterestRate,8,12);}DataClass中的GetLoanDTOs方法可以重构为接受一个整数参数，用于限制要返回的记录数，以填充执行Test_CalculateLoan_ShouldReturnCorrectRate所需的数据行：
publicclassDataClass{publicstaticIEnumerable
让我们创建一个LoanDTOData类，用于提供数据以测试Test_CalculateLoan_ShouldReturnCorrectRate方法。LoanDTOData将返回LoanDTO的IEnumerable对象：
publicclassLoanDTOData:IEnumerable
[Theory,ClassData(typeof(LoanDTOData))]publicvoidTest_CalculateLoan_ShouldReturnCorrectRate(LoanDTOloanDTO){Loanloan=carLoanCalculator.CalculateLoan(loanDTO);Assert.NotNull(loan);Assert.InRange(loan.InterestRate,8,12);}使用任何合适的方法，都可以灵活地实现枚举器，无论是使用类属性还是方法。在运行测试之前，xUnit.net框架将在类上调用.ToList()。在使用ClassData属性将数据传递给您的测试时，您总是需要创建一个专用类来包含您的数据。
在项目的SqlDataExample文件夹中，有一些文件可以复制到您的项目中，以便为您提供直接连接到SQLServer数据库或可以使用OLEDB访问的任何数据源的功能。该文件夹中的四个类是DataAdapterDataAttribute，DataAdapterDataAttributeDiscoverer，OleDbDataAttribute和SqlServerDataAttribute。
需要注意的是，由于.NETCore不支持OLEDB，因此无法在.NETCore项目中使用前面的扩展。这是因为OLEDB技术是基于COM的，依赖于仅在Windows上可用的组件。但是您可以在常规.NET项目中使用此扩展。
GitHub上的xUnit.net存储库中提供了SqlServerData属性的代码清单，该属性可用于装饰数据理论，以直接从MicrosoftSQLServer数据库表中获取测试执行所需的数据。
为了测试SqlServerData属性，您应该在您的SQLServer实例中创建一个名为TheoryDb的数据库。创建一个名为Palindrome的表；它应该有一个名为varchar的列。用样本数据填充表，以便用于测试：
CREATETABLE[dbo].PalindromeNOTNULL);INSERTINTO[dbo].[Palindrome]([word])VALUES('civic')GOINSERTINTO[dbo].[Palindrome]([word])VALUES('dad')GOINSERTINTO[dbo].[Palindrome]([word])VALUES('omo')GOPalindronmeChecker类运行一个IsWordPalindrome方法来验证一个单词是否是回文，如下面的代码片段所示。回文是一个可以在两个方向上阅读的单词，例如dad或civic。在不使用算法实现的情况下，快速检查这一点的方法是反转单词并使用字符串SequenceEqual方法来检查这两个单词是否相等：
publicclassPalindromeChecker{publicboolIsWordPalindrome(stringword){returnword.SequenceEqual(word.Reverse());}}为了测试IsWordPalindrome方法，将实现一个测试方法Test_IsWordPalindrome_ShouldReturnTrue，并用SqlServerData属性进行装饰。此属性需要三个参数——数据库服务器地址、数据库名称和用于从包含要加载到测试中的数据的表或视图中检索数据的选择语句：
publicclassPalindromeCheckerTest{[Theory,SqlServerData(@".\sqlexpress","TheoryDb","selectwordfromPalindrome")]publicvoidTest_IsWordPalindrome_ShouldReturnTrue(stringword){PalindromeCheckerpalindromeChecker=newPalindromeChecker();Assert.True(palindromeChecker.IsWordPalindrome(word));}}当运行Test_IsWordPalindrome_ShouldReturnTrue时，将执行SqlServerData属性，以从数据库表中获取记录，用于执行测试方法。要创建的测试数量取决于表中可用的记录。在这种情况下，将创建并执行三个测试：
与xUnit.netGitHub存储库中可用的SqlServerData属性类似，您可以创建一个自定义属性来从任何源加载数据。自定义属性类必须实现DataAttribute，这是一个表示理论要使用的数据源的抽象类。自定义属性类必须重写并实现GetData方法。该方法返回IEnumerable
让我们创建一个CsvData自定义属性，可以用于从.csv文件中加载数据，用于数据驱动的单元测试。该类将具有一个构造函数，它接受两个参数。第一个是包含.csv文件的完整路径的字符串参数。第二个参数是一个布尔值，当为true时，指定是否应使用包含在.csv文件中的数据的第一行作为列标题，当为false时，指定忽略文件中的列标题，这意味着CSV数据从第一行开始。
自定义属性类是CsvDataAttribute，它实现了DataAttribute类。该类用AttributeUsage属性修饰，该属性具有以下参数—AttributeTargets用于指定应用属性的有效应用元素，AllowMultiple用于指定是否可以在单个应用元素上指定属性的多个实例，Inherited用于指定属性是否可以被派生类或覆盖成员继承：
[AttributeUsage(AttributeTargets.Method,AllowMultiple=false,Inherited=false)]publicclassCsvDataAttribute:DataAttribute{privatereadonlystringfilePath;privatereadonlyboolhasHeaders;publicCsvDataAttribute(stringfilePath,boolhasHeaders){this.filePath=filePath;this.hasHeaders=hasHeaders;}//TobefollowedbyGetDataimplementation}下一步是实现GetData方法，该方法将覆盖DataAttribute类中可用的实现。此方法使用System.IO命名空间中的StreamReader类逐行读取.csv文件的内容。实现了第二个实用方法ConverCsv，用于将CSV数据转换为整数值：
publicoverrideIEnumerable