c# 持续集成 单元测试_如何在不进行单元测试的情况下设置持续集成

c# 持续集成 单元测试

Do you think continuous integration is not for you because you have no automated tests? Or no unit tests at all? Not true. Tests are important. But there are many more aspects to continuous integration than just testing. Let's see what they are.

您是否认为持续集成不适合您，因为您没有自动化测试？ 还是根本没有单元测试？ 不对。 测试很重要。 但是，持续集成有很多方面，而不仅仅是测试。 让我们看看它们是什么。

1.构建代码库 (1. Building the codebase)

This is the most critical issue continuous integration should solve. The main branch of your codebase should always build/compile. It seems silly to even mention it.

这是持续集成应解决的最关键问题。 您的代码库的主要分支应始终生成/编译。 甚至提到它似乎很愚蠢。

Take a team of 12. Say 1 faulty commit gets into the main branch. Everybody pulls. Here starts the process of finding out what's wrong and coordinating who should or will fix it. The confusion puts your whole team out of focus for around 30 minutes. Plus it causes frustration.

以12人为一组。假设1个错误的提交进入主分支。 大家拉。 从这里开始找出问题所在并协调谁应该或将要修复它的过程。 混乱会使整个团队失去焦点大约30分钟。 再加上它会导致沮丧。

Let's say this happens once a week (everybody makes mistakes eventually). 30 minutes x 12 people is 8 lost hours per week.

假设这种情况每周发生一次(每个人最终都会犯错误)。 30分钟x 12人每周损失8个小时。

If you are OK with that you might as well:

如果您还可以的话，也可以：

• set up a CI process preventing faulty builds from getting into the main branch
  设置CI流程，以防止错误的构建进入主分支
• give away a day off to one developer every week
  每周给一位开发人员放假

Same outcome, happier team :)

结果相同，团队更快乐:)

Setting up a CI process that ensures your codebase compiles is less than half a day's work. It's worth the effort.

设置确保您的代码库编译的CI流程不到半天的时间。 值得付出努力。

2.静态代码分析 (2. Static code analysis)

This comes for free in almost every language and is a one liner to run against a predefined set of rules:

几乎每种语言都免费提供此服务，并且可以按照预定义的规则运行：

• Javascript: eslint, tslint

  Javascript： eslint ， tslint

• Java: sonarlint

  Java： sonarlint

• Python: pylint

  Python： pylint

• Go: golint

  围棋： golint

Setting up the static code analysis (or linting) takes 1 hour or so. So what are the benefits? You have well-formatted and "by the book" code in your main branch. That's a clear quality increase for your code base.

设置静态代码分析(或插入)需要1个小时左右。 那有什么好处呢？ 您已经在主分支中设置了格式正确的代码，并且“按书”代码。 对于您的代码库而言，这显然是质量的提高。

If that is the least of your problems because your team is always rushing to meet deadlines, think of it this way. Your code review process will be faster. Anything that is in the area of code structure, best practices etc. is already checked by your CI process. No need to review or discuss it. Your developers can focus on the business content of code reviews.

如果那是您问题中最少的问题，因为您的团队总是急于按时完成任务，请以这种方式思考。 您的代码审核过程将更快。 CI程序已经检查了代码结构，最佳实践等方面的所有内容。 无需审查或讨论。 您的开发人员可以专注于代码审查的业务内容。

Great bonus: developers learn the code conventions automatically. The static analysis tool provides shows you the violated rule and explains why it is wrong to do that thing.

巨大的好处：开发人员可以自动学习代码约定。 静态分析工具向您显示违反的规则，并解释为什么这样做是错误的。

A hurdle with conventions is that developers are dogmatic about, for example, tabs versus spaces or those sorts of things. At the end of the day good conventions are those that are followed by all. Pick a set of standard conventions and roll with them.

约定的障碍是，开发人员对于例如制表符与空格或诸如此类的事情是教条主义的。 归根结底，良好的惯例是所有人遵循的惯例。 选择一组标准约定并将其滚动。

3.文化变革 (3. Culture change)

Continuous Integration is not a technical problem. It's a team process. You want to work in small increments and integrate code to the main branch often. See How to get started with CI for a larger discussion on what the culture goal actually is.

持续集成不是技术问题。 这是一个团队过程。 您希望以较小的增量工作，并经常将代码集成到主分支中。 有关文化目标实际上是什么的更多讨论，请参见如何开始使用CI 。

After the team masters the first critical elements, another shift should happen. People will realize that working in smaller increments is more efficient. Automated checks for basic mistakes will boost your confidence so you can merge code faster.

在团队掌握了第一批关键要素之后，应该再发生一次转变。 人们会意识到，以较小的增量进行工作会更有效率。 自动检查基本错误将增强您的信心，因此您可以更快地合并代码。

As a result, a branch's life span will decrease. Code review will be faster. Everybody will work with almost the latest code. It will prevent drifts and merge conflicts due to people working apart. See Why you should not use feature branches for a full list of benefits.

结果，分支的寿命将减少。 代码审查将更快。 每个人都将使用几乎最新的代码。 它可以防止由于人员分工而造成的漂移和合并冲突。 请参阅为什么不应该使用功能分支获取全部好处。

At the end of the day CI helps our pride and ego. Everybody should be happy to have a tool to catch their mistakes before they reach the world.

归根结底，CI有助于我们的骄傲和自我。 每个人都应该很高兴拥有一个能够在错误出现之前就发现错误的工具。

你是如何开始的？ (How do you get started?)

Here is a very simple and actionable process to get started. It works regardless of your git provider: GitHub, Bitbucket, Gitlab, Azure DevOps, and all the others.

这是一个非常简单且可行的过程。 无论您的git提供程序如何，它都可以工作：GitHub，Bitbucket，Gitlab，Azure DevOps以及其他所有代码。

1.启用拉取请求(PR)流程 (1. Enable a Pull Request (PR) process)

Lock your main branch from direct pushes. Everything should come through PRs. Here are links on how to do this for Github, Bitbucket, GitLab, and Azure DevOps.

锁定主分支以免直接推动。 一切都应通过PR。 以下是有关如何为Github ， Bitbucket ， GitLab和Azure DevOps执行此操作的链接。

2.选择一个CI平台 (2. Pick a CI platform)

Every git provider allows you to define build pipelines for your PRs. The builds will run when the PR is created and for each new push to the branch the PR carries. A pre condition to complete your PR (= merge your branch) will be a successful build.

每个git提供程序都允许您为PR定义构建管道。 该构建将在创建PR时运行，并且对于PR进行的每次新的分支推送。 完成PR(=合并分支)的前提是构建成功。

The big CI players are CircleCI, Codeship, and Travis CI. I of course recommend Fire CI since its the platform I've built. But I don't claim it is better than the rest for each and every use case.

CI的主要参与者是CircleCI，Codeship和Travis CI。 我当然推荐Fire CI，因为它是我构建的平台。 但是我并没有说它在每个用例中都比其余的要好。

Just pick one and get started.

只需选择一个就可以开始。

3.定义2个班轮版本 (3. Define a 2 liner build)

The most basic build we want to achieve is build + static code analysis. Getting there is 2 or 3 commands in a shell.

我们要实现的最基本的构建是构建+静态代码分析。 在shell中到达那里有2或3个命令。

All CI platforms go for "configuration as code". You define your build in a *.yml file at the root of your repository and the platform picks it up.

所有CI平台都采用“代码配置”。 您在存储库根目录的* .yml文件中定义构建，然后平台将其选中。

With Fire CI, for example, you would need to add a .fire.yml file at the root of your repo that would look like this:

例如，使用Fire CI，您需要在仓库的根目录中添加一个.fire.yml文件，如下所示：

pipeline:   dockerfile: Dockerfile

Then you add a file named "Dockerfile" to build your app. Here are a few examples of simple Dockerfiles.

然后，添加一个名为“ Dockerfile”的文件以构建您的应用程序。 以下是一些简单Dockerfile的示例。

Any yarn/npm based tech like React/Angular/Vue/Node:

任何基于yarn / npm的技术，例如React / Angular / Vue / Node：

FROM python:3 
WORKDIR /app  
COPY . . 
RUN yarn
RUN yarn lint 
RUN yarn build

Python:

Python：

FROM python:3
WORKDIR /app 
COPY . .
RUN pip install all_your_dependencies
RUN pylint all_your_python_files.py

Go:

走：

FROM golang:latest
WORKDIR /app
COPY . .
RUN go build -o main .

I could go on with many more. These examples are simplistic and could be improved with a few more commands. But you get the point: it's easy.

我可以继续下去。 这些示例非常简单，可以通过添加一些命令来进行改进。 但您明白了：这很容易。

可选：启用代码审查 (Optional: Enable code reviews)

Now that every code contribution comes through a PR, code reviews are easy to do. Every git provider has an awesome UI to present the differences and allow you to comment on code.

现在，每个代码贡献都来自PR，代码审查变得容易。 每个git提供程序都有一个很棒的UI来显示差异并允许您对代码进行注释。

If you are new to the process do not define a mandatory set of reviewers as it will slow your team down. Do start a best effort process to review each others' code. And build on that.

如果您不熟悉此流程，请不要定义一组必填的审阅者，因为这会使您的团队慢下来。 请尽最大努力来检查彼此的代码。 并以此为基础。

然后怎样呢？ (What then?)

As with everything, think big but start small. Having a CI process in place opens a world of opportunities.

与所有事物一样，从大处着眼，从小处开始。 实施CI流程将打开机遇之门。

测试中 (Testing)

Once you have the basic process in place, it becomes a breeze to add your first automated test. And then some others. Low yet continuous effort can bring you awesome test coverage before you know it.

完成基本流程后，添加第一个自动化测试变得轻而易举。 还有一些。 不费吹灰之力和持续不断的努力可以为您带来无与伦比的测试覆盖率。

I recommend that you remain lean and not invest effort into writing tests. Check what breaks often or requires a lot of effort to test manually. Automate that. Always keep productivity in mind. Having a ton of tests just because is worth nothing.

我建议您保持精干，不要花精力编写测试。 检查哪些经常中断或需要大量的精力进行手动测试。 自动化。 始终牢记生产力。 仅仅因为一无所有而进行大量测试就一文不值。

其他津贴 (Other perks)

There are many tools out there that you can integrate to your CI process. They are not key but the effort versus benefits could be worthwhile.

您可以将许多工具集成到CI流程中。 它们不是关键，但是努力与收益是值得的。

A few examples are below. Links are for the GitHub marketplace but other git providers integrate as easily.

下面是一些示例。 链接是针对GitHub市场的，但是其他git提供程序也可以轻松集成。

• Automatic update of dependencies: Depfu suggests dependencies to you to update automatically. This way you remain up to date doing small increments. This is always better than a once a year "let's bump everything" strategy.

  自动更新依赖关系： Depfu建议您自动更新依赖关系。 这样，您就可以以小幅增量保持最新状态。 这总是比每年一次的“让一切都变样”的策略更好。

• Open source security: Snyk warns you about security threats in open source libraries.

  开源安全性： Snyk警告您有关开源库中的安全威胁。

• Images optimisation: ImgBot detects large images in your repository and submits a PR with size optimized version. Relevant for front end projects, but still nice.

  图像优化： ImgBot在您的存储库中检测到大图像，并提交具有尺寸优化版本的PR。 与前端项目有关，但仍然不错。

There are many more out there. Browse the marketplace for things that could solve a problem for you.

还有更多。 浏览市场，寻找可以为您解决问题的事物。

Careful though! Resist the urge to use everything that comes to mind. Pick the ones that really provide a productivity boost. Free metrics or tools that you don't consider carefully are harmful as people are not sure what to do with them.

小心点！ 抵制使用想到的一切的冲动。 选择那些真正可以提高生产力的产品。 您不会仔细考虑的免费指标或工具有害无益，因为人们不确定该如何处理。

结论 (Conclusion)

You do not need fancy tests suites to get started with Continuous Integration.

您不需要高级测试套件即可开始进行持续集成。

Literally 2 hours of effort can get you rolling. And it'll enable a virtuous circle for your team's productivity.

从字面上看，2个小时的工作可以让您滚动。 这将为您的团队的生产力带来一个良性循环。

The bigger your team and your projects, the greater the benefits. In 2020 there is no good reason to not have a CI process.

您的团队和项目越大，收益越大。 在2020年，没有充分的理由不进行CI程序。

Feel free to contact me if you need help setting up a CI process for your team. I'll be happy to help if I can.

如果需要帮助为您的团队设置CI流程，请随时与我联系 。 如果可以的话，我很乐意提供帮助。

Thanks for reading and good luck!Originally published on The Fire CI Blog.

感谢您的阅读和好运！ 最初发布在Fire CI博客上。

翻译自: https://www.freecodecamp.org/news/continuous-integration-without-unit-tests/

c# 持续集成 单元测试