Java >> Java Tutorial >  >> Java

Ausführen von TestProject OpenSDK-Tests mit Github-Aktionen

Java

In den vorherigen Teilen meines TestProject OpenSDK-Tutorials wurde beschrieben, wie Sie Tests für Webanwendungen schreiben können, indem Sie sowohl TestProject OpenSDK als auch verwenden JUnit 5.

Das Problem ist jedoch, dass automatisierte Tests nicht sehr nützlich sind, wenn sie nicht regelmäßig ausgeführt werden. Dieser Blogbeitrag beschreibt, wie Sie dieses Problem mithilfe von Github Actions lösen können.

Nachdem Sie diesen Blogbeitrag gelesen haben, werden Sie:

  • Verstehen Sie, warum Sie eine Continuous Integration (CI)-Pipeline erstellen sollten, die Ihre Tests ausführt.
  • Wissen Sie, wie Sie Ihren TestProject-API-Schlüssel erhalten.
  • Kann eine einfache CI-Pipeline erstellen, die Ihre Tests mithilfe von Github-Aktionen ausführt.

Fangen wir an.

Warum sollten Sie eine CI-Pipeline erstellen?

Wikipedia definiert den Begriff Continuous Integration wie folgt:

In der Softwareentwicklung ist kontinuierliche Integration (CI) die Praxis, die Arbeitskopien aller Entwickler mehrmals täglich zu einer gemeinsamen Hauptlinie zusammenzuführen.

Wenn Sie diesen Ansatz verwenden, ist es wichtig, dass Sie diese beiden Regeln befolgen:

  • Bevor Sie Ihren Code mit der gemeinsam genutzten Hauptlinie zusammenführen können, müssen Sie sicherstellen, dass Ihr Code wie erwartet funktioniert. Diese Regel wird normalerweise erzwungen, indem automatisierte Tests ausgeführt und der Code überprüft wird, bevor er mit der gemeinsamen Hauptlinie zusammengeführt wird.
  • Nachdem Sie Ihren Code mit der gemeinsam genutzten Hauptleitung zusammengeführt haben, müssen Sie überprüfen, ob die gemeinsam genutzte Hauptleitung wie erwartet funktioniert. Diese Regel wird normalerweise erzwungen, indem automatisierte Tests ausgeführt werden, nachdem jemand Code mit der gemeinsam genutzten Hauptlinie zusammengeführt hat.

Diese Regeln sind wichtig, weil sie sicherstellen, dass der Code, der von der gemeinsam genutzten Hauptlinie gefunden wird, funktioniert und jederzeit freigegeben werden kann. Da die gemeinsam genutzte Hauptleitung funktioniert, müssen Ihre Teammitglieder auch keine Zeit mit der Reparatur von fehlerhaftem Code verschwenden. Stattdessen können sie sich auf die Entwicklung neuer Funktionen konzentrieren.

Außerdem ist es wichtig zu verstehen, dass diese Regeln zwar eindeutig nützlich sind, ihre Befolgung jedoch nicht ausreicht. Beispielsweise können Sie automatisierte Tests manuell ausführen, bevor Sie Code mit der gemeinsam genutzten Hauptlinie zusammenführen und nachdem Sie Code mit der gemeinsam genutzten Hauptlinie zusammengeführt haben. Dieser Ansatz hat drei Probleme:

  • Es ist äußerst irritierend und langsam, Code zu überprüfen, wenn Sie Tests durchführen müssen, bevor Sie den "Produktionscode" überprüfen können. Leider bedeutet dies, dass die Leute die Tests ignorieren und nur den Produktionscode überprüfen. Mit anderen Worten, der Überprüfungsprozess ist unzuverlässig und Sie können nicht darauf vertrauen, dass der Code, der den Überprüfungsprozess besteht, funktioniert.
  • Sie können nicht darauf vertrauen, dass der von der gemeinsamen Hauptlinie gefundene Code funktioniert, weil früher oder später jemand fehlerhaften Code damit zusammenführt, weil er/sie vergessen hat, die Tests auszuführen. Mit anderen Worten, wenn Sie 100 % sicher sein müssen, dass der Code funktioniert, müssen Sie die Tests selbst durchführen.
  • Das manuelle Ausführen von Tests ist eine sehr langweilige und demotivierende Arbeit. Erschwerend kommt hinzu, dass die Person, die Tests für den von der gemeinsamen Hauptleitung gefundenen Code durchführt, nicht wirklich etwas anderes tun kann, da sie bereit sein muss, mögliche Probleme zu beheben, sobald sie sie bemerken.

Glücklicherweise ist die Lösung ziemlich offensichtlich. Da niemand seine Zeit mit automatisierbaren Arbeiten verschwenden sollte, müssen Sie eine CI-Pipeline erstellen, die Ihre Tests ausführt. Da in diesem Blogbeitrag davon ausgegangen wird, dass Sie Github Actions verwenden, muss Ihre CI-Pipeline Ihre Tests ausführen, wenn Sie eine neue Pull-Anforderung erstellen oder Code mit main zusammenführen (früher master )-Zweig.

Bevor Sie mithilfe von Github-Aktionen eine neue CI-Pipeline erstellen können, müssen Sie einen neuen TestProject-API-Schlüssel erstellen. Als nächstes erfahren Sie, wie das geht.

Erstellen eines neuen TestProject-API-Schlüssels

Wenn Sie TestProject OpenSDK-Tests mithilfe von Github-Aktionen ausführen möchten, müssen Sie den TestProject-Agenten mit Docker ausführen. Wenn Sie den Docker-Container starten, der den TestProject-Agenten ausführt, müssen Sie den TestProject-API-Schlüssel angeben, der vom TestProject-Agenten verwendet wird, wenn er mit der TestProject-Plattform kommuniziert.

Sie können Ihren TestProject-API-Schlüssel erstellen, indem Sie diesen Schritten folgen:

Zuerst , müssen Sie den Assistenten zum Erstellen von API-Schlüsseln starten, indem Sie diesen Schritten folgen:

  1. Melden Sie sich auf der Website app.testproject.io an.
  2. Öffnen Sie die Seite "Integrationen".
  3. Öffnen Sie den Abschnitt "API-Schlüssel".
  4. Klicken Sie auf die Schaltfläche "API-Schlüssel erstellen".

Die folgende Abbildung veranschaulicht diesen Schritt:

Zweite , müssen Sie den Namen Ihres API-Schlüssels konfigurieren. Nachdem Sie den Namen Ihres API-Schlüssels konfiguriert haben, können Sie mit dem nächsten Schritt des Assistenten fortfahren.

Die folgende Abbildung veranschaulicht diesen Schritt:

Dritter , müssen Sie die Projekte angeben, auf die mit dem erstellten API-Schlüssel zugegriffen werden kann. Sie können entweder Zugriff auf alle Projekte oder nur auf die angegebenen Projekte gewähren. Nachdem Sie bereit sind, Ihren API-Schlüssel zu erstellen, müssen Sie auf den Link „Fertig stellen“ klicken.

Die folgende Abbildung veranschaulicht diesen Schritt:

Nachdem Sie einen neuen API-Schlüssel erstellt haben, wird der erstellte API-Schlüssel auf der Seite „API-Schlüssel“ angezeigt und Sie können ihn in die Zwischenablage kopieren, indem Sie auf den Link „Kopieren“ klicken.

Die folgende Abbildung veranschaulicht das Layout der Seite „API-Schlüssel“:

Nachdem Sie Ihren neuen TestProject-API-Schlüssel erhalten haben, müssen Sie herausfinden, wie Sie Umgebungsvariablen an Ihren Github Actions-Workflow übergeben können. Lassen Sie uns weitermachen und herausfinden, wie Sie dieses Problem lösen können.

Erstellen der erforderlichen geheimen Github-Aktionen

Secrets sind im Grunde verschlüsselte Umgebungsvariablen, die in Github Actions-Workflows verwendet werden können. Bevor Sie den Github Actions-Workflow erstellen können, der Ihre Tests ausführt, müssen Sie zwei Geheimnisse erstellen:

  • Der TP_API_KEY secret enthält Ihren TestProject-API-Schlüssel. Der TestProject-Agent verwendet diesen API-Schlüssel, wenn er mit der TestProject-Plattform kommuniziert.
  • Die TP_DEV_TOKEN secret enthält Ihr TestProject-Entwickler-Token. Wie Sie sich erinnern, müssen Sie beim Konfigurieren von TestProject OpenSDK das TestProject-Entwicklertoken als Wert von TP_DEV_TOKEN festlegen Umgebungsvariable.

Wenn Sie ein neues Repository-Secret erstellen möchten, müssen Sie die folgenden Schritte ausführen:

  1. Öffnen Sie die Hauptseite Ihres Github-Repositorys.
  2. Öffnen Sie die Seite "Einstellungen".
  3. Öffnen Sie den Abschnitt "Geheimnisse".
  4. Klicken Sie auf die Schaltfläche „Neues Repository-Secret“, die sich in der oberen rechten Ecke der Seite „Secrets“ befindet. Diese Schaltfläche öffnet eine neue Seite, auf der Sie ein neues Repository-Secret erstellen können.

Die folgende Abbildung veranschaulicht das Layout der Seite „Geheimnisse“:

Als Nächstes erfahren Sie, wie Sie den Github Actions-Workflow erstellen können, der Ihre Tests ausführt.

Erstellen des Github Actions-Workflows, der Ihre Tests ausführt

Sie können den Github Actions-Workflow erstellen, der Ihre Tests ausführt, indem Sie diesen Schritten folgen:

Wenn Sie mit Github Actions nicht vertraut sind, empfehle ich Ihnen, dieses Tutorial zu lesen, bevor Sie mit dem Lesen dieses Blogbeitrags fortfahren.

Zuerst müssen Sie eine YAML-Datei erstellen, die Ihren Github Actions-Workflow konfiguriert, und diese Datei in /.github/workflows ablegen Verzeichnis.

Zweite , müssen Sie den Namen Ihres Workflows konfigurieren. Danach sieht Ihre Workflow-Datei wie folgt aus:

name: Run TestProject OpenSDK Tests

Dritter , müssen Sie die Ereignisse konfigurieren, die Ihren Workflow auslösen. Weil Sie eine CI-Pipeline erstellen müssen, die Ihre Tests ausführt, wenn Sie eine neue Pull-Anforderung erstellen oder Code mit main zusammenführen (früher master ) Branch müssen Sie sicherstellen, dass Ihr Github Actions-Workflow ausgelöst wird, wenn Sie eine neue Pull-Anforderung an main erstellen verzweige oder pushe den Code zum main Zweig.

Nachdem Sie die Ereignisse konfiguriert haben, die Ihren Github Actions-Workflow auslösen, sieht Ihre Workflow-Datei wie folgt aus:

name: Run TestProject OpenSDK Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

Vierter , müssen Sie Ihrem Github Actions-Workflow einen neuen Job hinzufügen und sicherstellen, dass dieser Job ausgeführt wird, indem Sie die neueste Ubuntu-Version verwenden, die von Github Actions unterstützt wird.

Nachdem Sie diesen Job zu Ihrem Github Actions-Workflow hinzugefügt haben, sieht Ihre Workflow-Datei wie folgt aus:

name: Run TestProject OpenSDK Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  build:
    runs-on: ubuntu-latest

Fünfter , müssen Sie den steps hinzufügen Abschnitt zu Ihrer Workflow-Datei. Dieser Abschnitt konfiguriert die Schritte des Jobs, der Ihre Tests ausführt. Danach sieht Ihre Workflow-Datei wie folgt aus:

name: Run TestProject OpenSDK Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  build:
    runs-on: ubuntu-latest

    steps:

Sechster , müssen Sie den Code überprüfen. Dadurch wird sichergestellt, dass Ihr Github Actions-Workflow auf den Code zugreifen kann. Nachdem Sie den erforderlichen Schritt zu Ihrem Github Actions-Workflow hinzugefügt haben, sieht Ihre Workflow-Datei wie folgt aus:

name: Run TestProject OpenSDK Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

Siebter , müssen Sie die JDK-Version (15) konfigurieren, die von Ihrem Workflow verwendet wird. Nachdem Sie die JDK-Version konfiguriert haben, sieht Ihre Workflow-Datei wie folgt aus:

name: Run TestProject OpenSDK Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - name: Configure JDK version
        uses: actions/setup-java@v1
        with:
          java-version: 15

Achte müssen Sie den TestProject-Agenten wie folgt ausführen:

  1. Erstellen Sie eine Docker-Compose-Datei, die den TestProject-Agenten ausführt. Der einfachste Weg, dies zu tun, ist die Verwendung der Docker-Compose-Datei, die von TestProject bereitgestellt wird. Wenn Sie die von TestProject bereitgestellte Datei verwenden, können Sie den TestProject-API-Schlüssel mithilfe von envsubst.
    2. an den gestarteten TestProject-Agenten übergeben
  2. Speichern Sie den Wert von TP_API_KEY Repository-Geheimnis im TP_API_KEY Umgebungsvariable.
  3. Ersetzen Sie ${TP_API_KEY} Variable, die aus der Docker-Compose-Datei mit dem Wert von TP_API_KEY gefunden wurde Umgebungsvariable.
  4. Starten Sie den Docker-Container, der den TestProject-Agenten ausführt.

Nachdem Sie einen neuen Schritt erstellt haben, der den TestProject-Agenten ausführt, sieht Ihre Workflow-Datei wie folgt aus:

name: Run TestProject OpenSDK Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - name: Configure JDK version
        uses: actions/setup-java@v1
        with:
          java-version: 15
      - name: Run TestProject agent
        env:
          TP_API_KEY: ${{ secrets.TP_API_KEY }} 
        run: |
          envsubst < .github/ci/docker-compose.yml > docker-compose.yml
          docker-compose -f docker-compose.yml up -d

Neunte müssen Sie sicherstellen, dass Ihr Workflow wartet, bis der TestProject-Agent bereit ist, Ihre Tests auszuführen.

Wenn Sie den Status eines TestProject-Agenten erhalten möchten, müssen Sie einen GET senden Anfrage an die URL:http://[host]:[port]/api/status . Wenn Sie einen GET senden Anfrage an die angegebene URL, gibt der TestProject-Agent das folgende JSON-Dokument zurück:

{
	"installPath":"/Applications/TestProject Agent.app/Contents/Resources",
	"registered":true,
	"operatingSystem":"Mac OS X",
	"machineName":"Petris-MacBook-Pro.local",
	"dataPath":"/Users/loke/Library/Application Support/TestProject/Agent",
	"logevents":false,
	"authorized":true,
	"guid":"nA2o8Exc7UykZN-z6LQwLg",
	"alias":"Petri's Agent",
	"ipAddresses":["192.168.0.3"],
	"tag":"0.66.2",
	"state":"Idle",
	"id":585304,
	"storedIdentities":["hyuGRTfdsCVRscxRTEwesd"],
	"fsmState":"Idle"
}

Wenn Sie sicherstellen möchten, dass Ihr TestProject-Agent bereit ist, Ihre Tests auszuführen, müssen Sie den Wert von registered überprüfen Attribut. Wenn der Wert dieses Attributs true ist , kann der TestProject-Agent Ihre Tests ausführen.

Wenn Sie einen Schritt erstellen möchten, der wartet, bis der TestProject-Agent bereit ist, Ihre Tests auszuführen, müssen Sie die folgenden Schritte ausführen:

  1. Verwenden Sie die Aktion "Auf API warten".
  2. Senden Sie einen GET Anfrage an die URL:http://localhost:8585/api/status .
  3. Warten Sie, bis der Wert von registered angezeigt wird Attribut ist true .
  4. Eine HTTP-Anfrage pro Sekunde senden.
  5. Wenn der TestProject-Agent nach Ablauf von 60 Sekunden noch nicht bereit ist, Ihre Tests auszuführen, setzen Sie den Arbeitsablauf fort.

Nachdem Sie Ihrem Github Actions-Workflow einen neuen Schritt hinzugefügt haben, sieht Ihre Workflow-Datei wie folgt aus:

name: Run TestProject OpenSDK Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - name: Configure JDK version
        uses: actions/setup-java@v1
        with:
          java-version: 15
      - name: Run TestProject agent
        env:
          TP_API_KEY: ${{ secrets.TP_API_KEY }} 
        run: |
          envsubst < .github/ci/docker-compose.yml > docker-compose.yml
          docker-compose -f docker-compose.yml up -d
      - name: Sleep until the TestProject agent can run tests
        uses: mydea/action-wait-for-api@v1
        with:
          url: http://localhost:8585/api/status
          expected-response-field: registered
          expected-response-field-value: true
          interval: 1
          timeout: 60

Zehnter , müssen Sie Ihre Tests mit Maven ausführen, indem Sie diesen Schritten folgen:

  1. Speichern Sie den Wert von TP_DEV_TOKEN Repository-Geheimnis im TP_DEV_TOKEN Umgebungsvariable. Dadurch wird sichergestellt, dass TestProject OpenSDK auf Ihr TestProject-Entwickler-Token zugreifen kann.
  2. Führen Sie den Befehl aus:mvn clean test .
  3. Konfigurieren Sie das Arbeitsverzeichnis, das Ihre POM-Datei enthält.

Nachdem Sie Ihrer Workflow-Datei einen neuen Schritt hinzugefügt haben, sieht sie wie folgt aus:

name: Run TestProject OpenSDK Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - name: Configure JDK version
        uses: actions/setup-java@v1
        with:
          java-version: 15
      - name: Run TestProject agent
        env:
          TP_API_KEY: ${{ secrets.TP_API_KEY }} 
        run: |
          envsubst < .github/ci/docker-compose.yml > docker-compose.yml
          docker-compose -f docker-compose.yml up -d
      - name: Sleep until the TestProject agent can run tests
        uses: mydea/action-wait-for-api@v1
        with:
          url: http://localhost:8585/api/status
          expected-response-field: registered
          expected-response-field-value: true
          interval: 1
          timeout: 60       
      - name: Run tests with Maven
        env:
          TP_DEV_TOKEN: ${{secrets.TP_DEV_TOKEN}}
        run: mvn clean verify
        working-directory: opensdk/code-reuse

Fahren wir fort und finden Sie heraus, wie Sie die Ergebnisse Ihres Github Actions-Workflows auf der Github-Benutzeroberfläche anzeigen können.

Untersuchen der Ergebnisse Ihres Github-Aktions-Workflows

Wenn Sie eine neue Pull-Anforderung erstellen, enthält die Hauptseite der Pull-Anforderung einen Abschnitt, der die Ergebnisse der aufgerufenen Github-Aktions-Workflows anzeigt. Dieser Abschnitt sieht wie folgt aus:

Wenn Sie einen genaueren Blick auf die Prüfungen werfen möchten, die für Ihren Pull-Request durchgeführt wurden, müssen Sie die Registerkarte „Prüfungen“ öffnen, indem Sie entweder auf den Link „Prüfungen“ oder „Alle Prüfungen anzeigen“ klicken. Die Registerkarte „Checks“ hat zwei Bereiche:

  • Der Bereich, der auf der linken Seite des Tabs „Checks“ angezeigt wird, ermöglicht Ihnen die Auswahl des angezeigten Checks.
  • Der Bereich auf der rechten Seite des Reiters 'Checks' zeigt die Konfiguration und Ausgabe des ausgewählten Checks an.

Die folgende Abbildung zeigt das Layout der Registerkarte „Checks“:

Wenn Sie Ihre PR mit main zusammenführen Branch führt Github den Workflow „Run TestProject OpenSDK Tests“ aus. Wenn die Tests fehlschlagen, erhalten Sie eine E-Mail, die wie folgt aussieht:

Sie können sich auch den Ausführungsverlauf Ihrer Github Actions-Workflows genauer ansehen. Wenn Sie dies tun möchten, müssen Sie im Hauptnavigationsmenü Ihres Github-Repositorys auf den Link „Aktionen“ klicken.

Die folgende Abbildung zeigt die Position dieses Links:

Auf der Seite „Aktionen“ können Sie den Workflow auswählen, dessen Ausführungsverlauf auf der Seite „Aktionen“ angezeigt wird. Wenn Sie sich einen bestimmten Workflow-Durchlauf genauer ansehen möchten, müssen Sie auf den Titel des Workflow-Durchlaufs klicken.

Die folgende Abbildung veranschaulicht das Layout der Seite „Aktionen“:

Sie haben jetzt eine einfache CI-Pipeline erstellt, die Ihre TestProject OpenSDK-Tests mithilfe von Github Actions ausführt, und Sie verstehen, wie Sie die Ergebnisse Ihrer Github Actions-Workflows genauer betrachten können. Fassen wir zusammen, was Sie aus diesem Blogbeitrag gelernt haben.

Zusammenfassung

Dieser Blogbeitrag hat Ihnen fünf Dinge beigebracht:

  • Sie müssen eine CI-Pipeline erstellen, wenn Sie sicherstellen möchten, dass der Code, der von der gemeinsamen Hauptleitung gefunden wird, funktioniert und jederzeit veröffentlicht werden kann.
  • Wenn Sie den Docker-Container starten, der den TestProject-Agenten ausführt, müssen Sie den TestProject-API-Schlüssel angeben, der vom TestProject-Agenten verwendet wird, wenn er mit der TestProject-Plattform kommuniziert.
  • Wenn Sie Umgebungsvariablen angeben möchten, die in Ihren Github Actions-Workflows verwendet werden können, müssen Sie Github Actions-Secrets verwenden.
  • Wenn Sie einen neuen Github Actions-Workflow erstellen möchten, müssen Sie Ihren Workflow mithilfe von YAML beschreiben.
  • Sie müssen Ihre Workflow-Dateien in /.github/workflows ablegen Verzeichnis.

Java-Tag