Testing is cheating, compiling is doubting

This article explores the concept, advantages, disadvantages, and a demonstration example of Continuous Integration (CI).

Historical Review

First, let’s take a brief look at the history.

In 1999, Kent Beck explored this topic in depth in his first book on Extreme Programming. In 2001, CruiseControl, one of the first open source CI tools, was born.

Why use CI?

The goal of CI is to execute automated tests after every code commit. This ensures that the code always remains functional. We call this continuous integration because every time the code is modified it is verified to ensure no regression issues occur.

Advantages

• Catch errors early: Problems are identified quickly, allowing for timely responses.
• Improving quality: Systematic testing ensures more robust code.
• Time Saving: Automated pipelines reduce the need for repetitive manual testing.

Disadvantages

• Initial Cost: Setting up CI can require significant initial investment and expertise.
• Execution time: Complex pipelines may extend the time it takes for developers to verify their code.

How it works

Before we understand how it works, let’s understand some terminology:

• Jobs: An instance of a container (usually Docker) used to execute scripts. This may include commands, tests, or simple operations such as echo.
• Pipeline: A series of jobs organized in sequence or in parallel. Each commit triggers this series of actions to validate the changes.

The principle is simple: each job returns a status code (success or failure). If a job fails, the pipeline will stop or skip subsequent steps depending on configuration.

Practical drill

We will use GitLab CI based examples. Can be configured through .gitlab-ci.yml files.

Basic Example

<code>image: alpine:latest

myjobname:
  script:
    - make</code>

Compile flags

Add compilation flags, there are two methods:

1. Pass rules in Makefile.
2. Pass flags directly in CI commands.

<code>myjobname_hard:
  script:
    - CFLAGS="-Wall -Werror" make
    # 或者
    - make compile_flags</code>

Using Criterion for testing and flagging

Criterion is a C language unit testing library.

Criterion installation

Before using Criterion for testing, you need to install Criterion.

<code>before_script:
  - apt-get update && apt-get install -y libcriterion-dev
script:
  - ./configure
  - make test</code>

Multi-stage construction

Split unit testing and functional testing into multiple phases, you can:

• Better Organized
• Better view of results

<code>stages:
  - build
  - test

build:
  stage: build
  script:
    - make all

test-unit:
  stage: test
  script:
    - make unit-test

test-functional:
  stage: test
  script:
    - make functional-test</code>

Use Clang to format code

Code formatting is crucial to maintaining a clean code base.

<code>image: alpine:latest

myjobname:
  script:
    - make</code>

Cache

In some cases it is useful to cache files or folders to avoid reloading them every time the pipeline is run.

A common example is the node_modules/ folder in JavaScript.

<code>myjobname_hard:
  script:
    - CFLAGS="-Wall -Werror" make
    # 或者
    - make compile_flags</code>

Of course, you can use additional options in the pipeline configuration to clear the cache if needed.

Artifact

Artifacts are CI-generated files that can be shared or downloaded across jobs.

For example, testing or coverage reports.

<code>before_script:
  - apt-get update && apt-get install -y libcriterion-dev
script:
  - ./configure
  - make test</code>

Test Coverage

Test coverage can be measured by integrating tools like gcovr or Cobertura in your CI pipeline.

<code>stages:
  - build
  - test

build:
  stage: build
  script:
    - make all

test-unit:
  stage: test
  script:
    - make unit-test

test-functional:
  stage: test
  script:
    - make functional-test</code>

Report

This code block allows you to integrate coverage reporting into your merge requests so that you can see the code that is not covered as well as the coverage percentage.

<code>clang_format:
  stage: format
  before_script:
    - apt-get -qq update && apt-get -qq install -y clang-format autotools-dev autoconf-archive gcovr libcriterion-dev
  script:
    - clang-format -i $(find src/ -type f -name "*.c") --dry-run --Werror</code>

Customized environment

You can specify the base environment for CI by selecting a specific Docker image.

<code>cache:
  paths:
    - node_modules/

install:
  script:
    - npm install</code>

Combining the above content, you can get the following example:

<code>artifacts:
  paths:
    - build/
    - reports/</code>

Note that the .h file is missing and before_script is missing.

Additional supplements

You can also check for junk files to make sure make clean is working properly.

<code>test-coverage:
  stage: test
  script:
    - gcovr --html --html-details -o coverage.html
  artifacts:
    paths:
      - coverage.html</code>

Summary

Continuous integration is an extremely powerful tool. While it can be difficult to set up, the benefits are huge.

The above is the detailed content of Testing is cheating, compiling is doubting. For more information, please follow other related articles on the PHP Chinese website!