首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

一文带你快速读懂.NET CLI(4)

一文带你快速读懂.NET CLI(4)

作为一个有经验的.NET开发人员,我非常担心临时/obj和/bin文件夹中残留的文件。因此,我在Visual Studio中使用“Clean Solution”命令,以防我试图改变引用的时候落下些什么。从命令行执行“dotnet clean”命令是完全相同的操作。

同样,针对众所周知的Nuget依赖问题,“dotnet restore”命令在解决方案中都试着去解决了。在这种情况下,使用“dotnet restore”可以让我们快速发现任何潜在的冲突或丢失的Nuget引用,而无需进行完整的编译,我在自己的工作中主要就采用该命令。在最新版本的dotnet cli中,在调用“dotnet build/test/pack/etc”时,会自动为您完成Nuget解析(该行为可以用标记覆盖),这将首先需要Nuget。

我们调用的“dotnet restore DotNetCliArticle.sln”干净利落地运行完毕,没有错误,所以我们终于可以准备编写一些代码了。让我们打开您选择的C#编辑器,向HeyWorld添加一个代码文件。测试项目包含一个非常简单的HTTP协议测试,它将指定我们希望从新的HeyWorld应用程序中的“GET: /”路由获得的行为:

using System.Threading.Tasks;using Alba;using Xunit;namespace HeyWorld.Tests{    public class verify_the_endpoint    {        [Fact]        public async Task check_it_out()        {            using (var system = SystemUnderTest.ForStartup\u0026lt;Startup\u0026gt;())            {                await system.Scenario(s =\u0026gt;                {                    s.Get.Url(\u0026quot;/\u0026quot;);                    s.ContentShouldBe(\u0026quot;Hey, world.\u0026quot;);                    s.ContentTypeShouldBe(\u0026quot;text/plain; charset=utf-8\u0026quot;);                });            }        }    }}

结果文件应该保存在具有适当名称(如verify_the_endpoints.cs)的HeyWorld.Tests目录。

在没有深入了解Alba机制前,我们的新HeyWorld应用的首页路由应该写出“Hey, world”。虽然我们还没有在HeyWorld应用中编写任何实际的代码,但是我们仍然可以运行这个测试,看看它能够连接正确,还是因为某些“理所当然的理由”而失败。

回到命令行,我可以使用以下命令运行测试项目中的所有测试:

dotnet test HeyWorld.Tests/HeyWorld.Tests.csproj

我们的一个测试会失败,因为还没有实现任何东西,它给了我们这样的输出:

Build started, please wait...Build completed.Test run for /Users/jeremydmiller/code/DotNetCliArticle/HeyWorld.Tests/bin/Debug/netcoreapp2.1/HeyWorld.Tests.dll(.NETCoreApp,Version=v2.1)Microsoft (R) Test Execution Command Line Tool Version 15.7.0Copyright (c) Microsoft Corporation. All rights reserved.Starting test execution, please wait...Total tests: 1. Passed: 1. Failed: 0. Skipped: 0.Test Run Successful.Test execution time: 2.4565 Seconds

为了把输出求和,执行了一个测试,但是失败了。我们还可以看到标准的xUnit输出,它提供了一些关于测试失败原因的信息。这里需要注意的是,“dotnet test”命令将返回一个退出代码,如果所有测试都通过,则返回0,表示成功;如果任何测试失败,则返回一个非零退出代码,表示失败。这对于持续集成(CI)脚本非常重要,大多数CI工具使用任何命令的退出代码来确定构建何时失败。

我认为上面的测试之所以失败是因为“理所当然的原因”,这意味着测试工具似乎能够引导真正的应用程序,我希望得到404响应,因为还没有编写任何代码。接下来,让我们为预期的行为实现一个MVC Core 端点:

public class HomeController : Controller{    [HttpGet(\u0026quot;/\u0026quot;)]    public string SayHey()    {        return \u0026quot;Hey, world!\u0026quot;;    }}

(注意,前面的代码应该作为HeyWorld\\startup.cs文件中的附加类添加)
返回列表