Continuous Testing w praktyce: jak zintegrować Postmana, Jenkins i GitHub Actions

🔧 Co to w ogóle jest Continuous Testing?

Zacznijmy od prostego pytania — po co to wszystko?

Continuous Testing to nie kolejny buzzword.
To podejście, w którym testy są częścią procesu dostarczania oprogramowania, a nie jego dodatkiem.
Czyli — każda zmiana w kodzie od razu uruchamia testy automatyczne, które:

• sprawdzają kluczowe endpointy API,

• walidują dane i odpowiedzi,

• generują raport z wynikami,

• i — co najważniejsze — blokują wdrożenie, jeśli coś się wykrzaczy.

Zasada jest prosta: im wcześniej znajdziesz błąd, tym mniej kosztuje.

🧠 Co wykorzystamy w tym przykładzie?

Będziemy potrzebować trzech rzeczy, które pewnie już dobrze znasz:

• Postman – do tworzenia i uruchamiania testów API,

• Jenkins – jako klasyczny serwer CI/CD,

• GitHub Actions – do uruchamiania testów bezpośrednio w chmurze GitHuba.

Dodatkowo przyda się:

• Newman (czyli CLI Postmana),

• Node.js zainstalowany lokalnie,

• i repozytorium na GitHubie, w którym będziemy przechowywać kolekcję testową.

🧩 Krok 1: Kolekcja testów w Postmanie

Zaczynamy od stworzenia kolekcji w Postmanie, która zawiera kilka requestów do naszego API.
Niech to będzie coś prostego, np. testy CRUD dla endpointu /users.

Każdy request ma przypisany skrypt testowy, np.:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Response time is less than 500ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

pm.test("User ID is present", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.id).to.exist;
})

Kiedy wszystko działa lokalnie — eksportujesz kolekcję i środowisko:
users_collection.json + env.json.

To nasze dwa główne pliki testowe.

⚙️ Krok 2: Uruchamianie testów z Newmana

Na tym etapie uruchamiasz testy z linii poleceń:

newman run users_collection.json -e env.json -r cli,html

Dzięki opcji -r html dostaniesz też raport w formacie HTML — idealny do późniejszego podpięcia pod pipeline.

To pierwszy dowód, że testy faktycznie działają poza Postmanem.
I to ważne — nigdy nie integruj w CI testów, które nie działają lokalnie. To klasyka błędów początkujących.

🧱 Krok 3: Jenkins – serce Continuous Testing

Czas przenieść to do Jenkinsa.
Tworzymy nowy projekt typu Freestyle (lub Pipeline, jeśli wolisz Jenkinsfile).

W kroku Build dodajemy polecenie:

npm install -g newman
newman run users_collection.json -e env.json -r cli,html

Aby testy się uruchamiały automatycznie, dodajemy trigger:

Build periodically: H/5 * * * *

czyli co 5 minut, albo lepiej — „Build when a change is pushed to GitHub”.

Efekt?
Po każdym pushu Jenkins automatycznie:

1. pobiera repo z GitHuba,

2. instaluje Newmana,

3. uruchamia testy,

4. generuje raport HTML,

5. i może wysłać powiadomienie na Slacka lub e-maila.

☁️ Krok 4: GitHub Actions – testy w chmurze

Dla lżejszych projektów Jenkins bywa zbyt ciężki.
Dlatego coraz częściej korzystam z GitHub Actions — to po prostu YAML-owy workflow, który odpala testy w chmurze.

Przykładowy plik .github/workflows/tests.yml:

name: API Tests

on:
  push:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Install Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install Newman
        run: npm install -g newman

      - name: Run API tests
        run: newman run users_collection.json -e env.json -r cli,html

Efekt jest dokładnie ten sam — tylko że tym razem wszystko działa bez serwera, bez Jenkinsa, bez ręcznego setupu.
Masz testy odpalane przy każdym pushu, a wyniki możesz podejrzeć w zakładce Actions.

🧾 Krok 5: Raporty, powiadomienia i analiza błędów

W testach automatycznych raport to złoto.
Bez niego nikt nie wie, co padło.

Newman pozwala generować raporty HTML, JSON, a nawet JUnit XML.
Jeśli chcesz zintegrować to z Jenkins Dashboardem, użyj wtyczki „HTML Publisher”.

W GitHub Actions też możesz dodać krok:

- name: Upload test report
  uses: actions/upload-artifact@v3
  with:
    name: postman-report
    path: newman/*.html

Dzięki temu masz dostęp do raportu z każdego runa.

🔄 Krok 6: Automatyczne zatrzymanie wdrożenia przy błędzie

To kluczowy moment.
Continuous Testing to nie tylko uruchamianie testów — to też zatrzymanie procesu, jeśli coś nie przeszło.

W praktyce:
Jeśli Newman zwróci exit code 1, pipeline się zatrzymuje, a wdrożenie nie przejdzie.

I właśnie o to chodzi.
Nie ma sensu deployować builda, jeśli testy mówią „coś jest nie tak”.

🧠 Co dalej można rozwinąć?

Kiedy masz już działające Continuous Testing, możesz iść krok dalej:

• 🔹 Integracja z Dockerem – odpalanie testów w kontenerze, np. docker run -v $(pwd):/etc/newman newman run ...

• 🔹 Dodanie raportów do Slacka – webhook z wynikami testów dla zespołu QA

• 🔹 Dynamiczne środowiska – zmienne środowiskowe z GitHub Secrets

• 🔹 Parallel execution – dzielenie testów na grupy i uruchamianie równolegle

W dużych projektach Continuous Testing staje się pełnoprawną częścią CI/CD – i nie chodzi już tylko o testy API, ale też o testy UI, wydajnościowe czy bezpieczeństwa.