Uruchamianie testów za pomocą GitHub Actions
Zintegrują Państwo automatyczne testy jednostkowe i integracyjne z potokiem CI, aby zapewnić jakość kodu i zapobiegać regresjom.
Uruchamianie testów za pomocą GitHub Actions to bezpłatna lekcja CI/CD with GitHub Actions & DevOps Pipelines na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej CI/CD with GitHub Actions & DevOps Pipelines, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs CI/CD with GitHub Actions & DevOps Pipelines zawiera 4 lekcji w sumie.
Dlaczego automatyzować testy w CI?
Proszę wyobrazić sobie, że wprowadzają Państwo zmianę w kodzie i od razu wiedzą, czy nie spowodowała ona problemów w innym miejscu. Na tym polega siła automatycznych testów w potoku CI!
Continuous Integration (CI), czyli ciągła integracja, polega na częstym scalaniu zmian w kodzie z centralnym repozytorium. Automatyczne testy pełnią funkcję strażników tego procesu.
Wcześnie wykrywają błędy, zapewniają szybką informację zwrotną i zwiększają pewność przy wprowadzaniu każdej zmiany w kodzie.
Rodzaje testów w potoku
Gdy mówimy o testach automatycznych, często wyróżniamy dwa główne rodzaje: testy jednostkowe i testy integracyjne.
- Testy jednostkowe: koncentrują się na małych, odizolowanych fragmentach kodu, takich jak pojedyncza funkcja lub metoda. Są szybkie i pozwalają precyzyjnie wskazać problemy.
- Testy integracyjne: sprawdzają, czy różne części systemu prawidłowo współpracują, na przykład czy kod poprawnie komunikuje się z bazą danych lub API.
Oba rodzaje są niezbędne, aby zapewnić solidność i niezawodność oprogramowania.
Automatyzowanie testów za pomocą GitHub Actions
GitHub Actions może pełnić funkcję osobistego narzędzia do uruchamiania testów, automatycznie wykonując je za każdym razem, gdy wypchną Państwo nowy kod.
Definiują Państwo workflow, który określa, kiedy go uruchomić, jakiego środowiska użyć i jakie polecenia wykonać.
Dzięki temu każda zmiana jest weryfikowana w spójny sposób, bez ręcznego wysiłku.
Przygotowanie projektu Java do testów
W demonstracji użyjemy prostego projektu Java zarządzanego za pomocą Maven, popularnego narzędzia do automatyzacji kompilacji.
Maven pomaga zarządzać zależnościami projektu oraz udostępnia polecenia do kompilowania kodu i uruchamiania testów.
Nasz projekt będzie zawierać prostą klasę Java i odpowiadający jej test JUnit (w ujęciu koncepcyjnym).
Nasz pierwszy uruchamialny przykład testu
Oto prosta klasa Java i podstawowy test sprawdzający jej działanie. Dla uproszczenia symulujemy test jednostkowy bez pełnej konfiguracji JUnit.
Metoda main pełni funkcję narzędzia uruchamiającego test i sprawdza, czy metoda add działa zgodnie z oczekiwaniami.
Proszę uruchomić przykład, aby zobaczyć wynik!
public class Calculator {
// Method to be tested
public int add(int a, int b) {
return a + b;
}
public static void main(String[] args) {
Calculator calc = new Calculator();
// Simulate a test case
int expected = 5;
int actual = calc.add(2, 3);
if (actual == expected) {
System.out.println("Test Passed: 2 + 3 = " + actual);
} else {
System.out.println("Test Failed: Expected " + expected + ", Got " + actual);
}
}
}Tworzenie workflowu testowego
Przyjrzyjmy się teraz, jak mógłby wyglądać plik workflowu GitHub Actions (.github/workflows/test.yml) uruchamiający nasze testy.
Ten plik YAML definiuje kroki, które GitHub Actions wykona, aby skonfigurować środowisko i uruchomić polecenia testowe.
Użyjemy polecenia Maven test, aby uruchomić rzeczywiste testy JUnit w prawdziwym projekcie.
name: Java CI with Maven
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up JDK 17
uses: actions/setup-java@v4
with:
java-version: '17'
distribution: 'temurin'
cache: maven
- name: Run Maven Tests
run: mvn test
Omówienie poszczególnych kroków workflowu
Przeanalizujmy najważniejsze kroki naszego workflowu testowego:
on: push / pull_request: uruchamia workflow po wypchnięciu kodu lub utworzeniu pull requesta do gałęzimain.runs-on: ubuntu-latest: określa system operacyjny maszyny wirtualnej (runnera), na której zostanie wykonany workflow.actions/checkout@v4: gotowa akcja, która pobiera kod repozytorium na runnera.actions/setup-java@v4: kolejna akcja, która konfiguruje Java Development Kit (JDK) na runnerze.run: mvn test: kluczowy krok! Wykonuje polecenie Maven, aby skompilować kod i uruchomić wszystkie zdefiniowane testy.
Obsługa niepowodzeń testów w CI
Jedną z najważniejszych zalet testów CI jest natychmiastowa informacja zwrotna. Jeśli którykolwiek test się nie powiedzie, zadanie workflowu GitHub Actions zakończy się niepowodzeniem.
Jest to wyraźny sygnał, że niedawna zmiana w kodzie wprowadziła błąd lub regresję.
Następnie mogą Państwo przejrzeć logi workflowu, aby dokładnie ustalić, który test się nie powiódł i dlaczego, co ułatwia szybkie rozwiązanie problemu.
Wpływ: jakość i pewność
Włączenie automatycznych testów do potoku CI jest jednym z fundamentów nowoczesnego tworzenia oprogramowania.
Aktywnie zapobiega regresjom, zapewnia stałą jakość kodu i znacznie zmniejsza ryzyko wdrożenia niedziałających funkcji.
Proces ten zwiększa zaufanie do bazy kodu, pozwalając zespołowi szybciej i niezawodniej wprowadzać innowacje.
Sprawdzenie workflowu testowego
Proszę rozważyć workflow GitHub Actions przeznaczony do uruchamiania testów. Jaki jest główny cel kroku run: mvn test w projekcie Java?
Podsumowanie: testowanie w potoku CI
W tej lekcji poznali Państwo sposób integrowania automatycznych testów z potokiem CI w GitHub Actions.
Omówiliśmy:
- znaczenie automatycznego testowania dla jakości kodu;
- różnice między testami jednostkowymi i integracyjnymi;
- strukturę workflowu GitHub Actions uruchamiającego testy Java za pomocą Maven;
- działanie kroków workflowu, takich jak
checkoutisetup-java; - kluczową rolę
mvn testw wykonywaniu testów; - sposób raportowania niepowodzeń testów przez GitHub Actions.
Automatyczne testowanie ma kluczowe znaczenie dla wczesnego wykrywania błędów i utrzymywania solidnej bazy kodu!
Często zadawane pytania
Czy lekcja „Uruchamianie testów za pomocą GitHub Actions” jest bezpłatna?
Tak — pełny tekst „Uruchamianie testów za pomocą GitHub Actions” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu CI/CD with GitHub Actions & DevOps Pipelines, przejdź na CoddyKit PRO. Kurs CI/CD with GitHub Actions & DevOps Pipelines zawiera 4 lekcji w sumie.
Co nauczysz się w „Uruchamianie testów za pomocą GitHub Actions”?
Zintegrują Państwo automatyczne testy jednostkowe i integracyjne z potokiem CI, aby zapewnić jakość kodu i zapobiegać regresjom. Ćwiczysz CI/CD with GitHub Actions & DevOps Pipelines z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć CI/CD with GitHub Actions & DevOps Pipelines?
Nie wymagamy żadnego doświadczenia. CI/CD with GitHub Actions & DevOps Pipelines w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.
Ile czasu zajmuje lekcja „Uruchamianie testów za pomocą GitHub Actions”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji CI/CD with GitHub Actions & DevOps Pipelines?
Tak. Każda lekcja CI/CD with GitHub Actions & DevOps Pipelines zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Wyzwalacze i zdarzenia workflow
- Uruchamianie testów za pomocą GitHub Actions
- Lintowanie i kontrola jakości kodu
- Buforowanie zależności na potrzeby szybszych kompilacji