加测试

这个仓库是一个 .NET 仓库。显然你不难理解它的项目结构，你可以先简单阅读一下它的代码。

它已经有完善的入口点、测试项目等。但是，目前社区普遍批评这个仓库的代码覆盖率很低。尤其是很多核心业务并没有被测试覆盖。

现在你需要扮演一位高级 .NET 专家，试图提高这个仓库的代码覆盖率。你可以直接去测试项目里增加新的 UT 。

注意，你没必要mock很多东西，例如数据库、文件系统等。它们在测试环境完全准备的也非常妥当了。你的测试大可以直接作为集成测试，也就是直接启动Web项目，调用它的API，检查返回效果。

被测试的项目中的用例，例如对外部仓库的访问，你也大可以直接让它真的去访问即可。除非是非常昂贵的请求，我们需要Mock。

Mock的方法就是在TestStartup里，对一个Service进行继承，override掉老方法，然后再把新服务替代老服务注册回去。

这样整个测试结构非常清晰。现在，你来试图开始增加几个新的测试类，覆盖一些核心功能吧！

如果老的代码实在有函数很难覆盖，考虑增加 [ExcludeFromCodeCoverage] 吧！

在写完测试以后，你可以使用 dotnet test 命令来执行你的测试。如果执行失败，除非你非常确定是真的源码业务逻辑有错误，否则不要修改源码。

修Lint

这是一个 .NET 仓库，它使用了 jb 来进行lint。当然，你可以直接运行其根目录下的 lint.sh 文件，以得到lint的结论。它可能无法通过lint。你会从STDOUT里阅读出无法通过的理由。

你的工作就是：首先分析他为什么无法通过lint，然后试图尽可能不break业务逻辑的修正lint的脚本指出的仓库的问题，也就是去修改 C#，然后重复运行 lint.sh 直到全部通过。

你不得修改 lint.sh 文件也不必要分析它！因为这个文件是用来lint的。如果它发现了错误，一定是仓库的错误，不是 linter 的！直接执行即可得到仓库本身的lint错误信息。

当然，最好你也跑一次 dotnet build 和 dotnet test，确保可以编译、UT全过。

尽可能最小化修改。我们的修改会被社区review。所以只修改必要的地方。不要添加无意义的注释或格式化。尽量不添加新包，不要改变现有的语法风格。

最后 git commit 并 git push 即可。message你可以自己写。从而帮助我修正这个仓库的问题。

加测试

这个仓库是一个 .NET 仓库。显然你不难理解它的项目结构，你可以先简单阅读一下它的代码。

它已经有完善的入口点、测试项目等。但是，目前社区普遍批评这个仓库的代码测试通过率很低，经常测试失败。

现在你需要扮演一位高级 .NET 专家，试图判断代码测试失败时，是测试用例的问题，还是环境的问题，还是真的发现了业务逻辑错误。

注意，你没必要mock很多东西，例如数据库、文件系统等。它们在测试环境完全准备的也非常妥当了。你的测试大可以直接作为集成测试，也就是直接启动Web项目，调用它的API，检查返回效果。

被测试的项目中的用例，例如对外部仓库的访问，你也大可以直接让它真的去访问即可。除非是非常昂贵的请求，我们需要Mock。

Mock的方法就是在TestStartup里，对一个Service进行继承，override掉老方法，然后再把新服务替代老服务注册回去。

这样整个测试结构非常清晰。现在，你来试图开始运行 dotnet test 得到测试结果，然后分析测试内容，讨论为什么失败，判断是真的bug还是用例问题，尝试缓解。

在写完测试以后，你可以使用 dotnet test 命令来执行你的测试。如果执行失败，除非你非常确定是真的源码业务逻辑有错误，否则不要修改源码。