Testen ist Betrug, Kompilieren ist Zweifeln

In diesem Artikel werden das Konzept, die Vor- und Nachteile sowie ein Demonstrationsbeispiel der kontinuierlichen Integration (CI) untersucht.

Historischer Rückblick

Werfen wir zunächst einen kurzen Blick auf die Geschichte.

1999 beschäftigte sich Kent Beck in seinem ersten Buch über Extreme Programming eingehend mit diesem Thema. Im Jahr 2001 wurde CruiseControl, eines der ersten Open-Source-CI-Tools, geboren.

Warum CI verwenden?

Das Ziel von CI besteht darin, nach jedem Code-Commit automatisierte Tests durchzuführen. Dadurch wird sichergestellt, dass der Code immer funktionsfähig bleibt. Wir nennen dies kontinuierliche Integration, da der Code bei jeder Änderung überprüft wird, um sicherzustellen, dass keine Regressionsprobleme auftreten.

Vorteile

• Fehler frühzeitig erkennen: Probleme werden schnell erkannt und ermöglichen zeitnahe Reaktionen.
• Qualität verbessern: Systematische Tests sorgen für robusteren Code.
• Zeitersparnis: Automatisierte Pipelines reduzieren den Bedarf an sich wiederholenden manuellen Tests.

Nachteile

• Anfangskosten: Die Einrichtung von CI kann erhebliche Anfangsinvestitionen und Fachwissen erfordern.
• Ausführungszeit: Komplexe Pipelines können die Zeit verlängern, die Entwickler benötigen, um ihren Code zu überprüfen.

Wie es funktioniert

Bevor wir verstehen, wie es funktioniert, wollen wir uns mit der Terminologie befassen:

• Jobs: Eine Instanz eines Containers (normalerweise Docker), der zum Ausführen von Skripten verwendet wird. Dies kann Befehle, Tests oder einfache Operationen wie Echo umfassen.
• Pipeline: Eine Reihe von Jobs, die nacheinander oder parallel organisiert sind. Jeder Commit löst diese Reihe von Aktionen aus, um die Änderungen zu validieren.

Das Prinzip ist einfach: Jeder Job gibt einen Statuscode zurück (Erfolg oder Misserfolg). Wenn ein Auftrag fehlschlägt, stoppt die Pipeline je nach Konfiguration die nachfolgenden Schritte oder überspringt sie.

Praktische Übung

Wir werden GitLab CI-basierte Beispiele verwenden. Kann über .gitlab-ci.yml-Dateien konfiguriert werden.

Grundlegendes Beispiel

<code>image: alpine:latest

myjobname:
  script:
    - make</code>

Flags kompilieren

Kompilierungsflags hinzufügen, es gibt zwei Methoden:

1. Regeln im Makefile übergeben.
2. Übergeben Sie Flags direkt in CI-Befehlen.

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

Verwendung von Criterion zum Testen und Markieren

Criterion ist eine Unit-Testing-Bibliothek für die C-Sprache.

Kriterieninstallation

Bevor Sie Criterion zum Testen verwenden, müssen Sie Criterion installieren.

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

Mehrstufiger Bau

Teilen Sie Unit-Tests und Funktionstests in mehrere Phasen auf. Sie können:

• Besser organisiert
• Bessere Sicht auf die Ergebnisse

<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>

Verwenden Sie Clang, um Code zu formatieren

Codeformatierung ist entscheidend für die Aufrechterhaltung einer sauberen Codebasis.

<code>image: alpine:latest

myjobname:
  script:
    - make</code>

Cache

In manchen Fällen ist es sinnvoll, Dateien oder Ordner zwischenzuspeichern, um zu vermeiden, dass sie bei jeder Ausführung der Pipeline neu geladen werden.

Ein häufiges Beispiel ist der Ordner node_modules/ in JavaScript.

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

Natürlich können Sie bei Bedarf zusätzliche Optionen in der Pipeline-Konfiguration nutzen, um den Cache zu leeren.

Artefakt

Artefakte sind CI-generierte Dateien, die auftragsübergreifend geteilt oder heruntergeladen werden können.

Zum Beispiel Test- oder Abdeckungsberichte.

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

Testabdeckung

Die Testabdeckung kann durch die Integration von Tools wie gcovr oder Cobertura in Ihre CI-Pipeline gemessen werden.

<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>

Bericht

Mit diesem Codeblock können Sie Abdeckungsberichte in Ihre Zusammenführungsanfragen integrieren, sodass Sie den nicht abgedeckten Code sowie den Abdeckungsprozentsatz sehen können.

<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>

Maßgeschneiderte Umgebung

Sie können die Basisumgebung für CI angeben, indem Sie ein bestimmtes Docker-Image auswählen.

<code>cache:
  paths:
    - node_modules/

install:
  script:
    - npm install</code>

Wenn Sie die oben genannten Inhalte kombinieren, erhalten Sie das folgende Beispiel:

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

Beachten Sie, dass die Datei .h fehlt und before_script fehlt.

Zusätzliche Ergänzungen

Sie können auch nach Junk-Dateien suchen, um sicherzustellen, dass make clean ordnungsgemäß funktioniert.

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

Zusammenfassung

Kontinuierliche Integration ist ein äußerst leistungsstarkes Tool. Auch wenn die Einrichtung schwierig sein kann, sind die Vorteile enorm.

Das obige ist der detaillierte Inhalt vonTesten ist Betrug, Kompilieren ist Zweifeln. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!