Odpowiedź.

Właściwe wersjonowanie i integracja testów automatycznych są kluczowe dla zapewnienia zgodności weryfikacji z aktualnym stanem projektu.

Historia zagadnienia

Testy automatyczne początkowo często były prowadzone oddzielnie od głównego projektu, co prowadziło do niezgodności i problemów z utrzymywaniem. Rozwój kilku gałęzi, częste wydania oprogramowania i testów — spowodowały potrzebę wspólnego systemu kontroli wersji.

Problem

Bez wersjonowania i skoordynowanej integracji powstają:

Uruchamianie nieaktualnych testów na zmienionym oprogramowaniu
"Złamanie" testów przy wprowadzeniu nowej funkcjonalności, która nie uwzględnia zmian w testach
Awaria w CI/CD

Rozwiązanie

Nowoczesne podejście:

Testy są przechowywane w wspólnym systemie kontroli wersji (najczęściej git)
Powiązanie gałęzi testowej z gałęzią rozwoju oprogramowania: w gałęzi feature — testy i kod są opracowywane razem
Automatyczne kontrole/budowy są przeprowadzane na podstawie pull requestów
Przegląd i zatwierdzanie zmian w testach i kodzie

# Ogólne podejście:
git checkout -b feature/new_login
# Funkcjonalność i testy są opracowywane i testowane razem
# Po przeglądzie są scalane razem do głównej gałęzi

Kluczowe cechy:

Spójność zmian w kodzie i testach (brak desynchronizacji)
Wygodne cofanie i porównywanie wersji (poprzez historię git)
Możliwość pracy zespołowej i przeglądu kodu testów automatycznych

Pytania podchwytliwe.

Czy testy mogą być przechowywane w oddzielnym repozytorium (od kodu projektu)?

Tak, ale wówczas trudniej jest utrzymać aktualność testów, wymaga to manualnej synchronizacji, istnieje ryzyko "zapomnienia" o aktualizacji czegoś przy wydaniu lub naprawie błędów.

Czy testy powinny od razu pokrywać całą nową funkcjonalność przy tworzeniu PR?

Idealnie — tak, w praktyce często pokrywają MVP/główne scenariusze w pierwszym PR, a złożone przypadki — jako oddzielne zadania. Najważniejsze, aby krytyczna funkcjonalność była od razu pokryta.

Czy można cofnąć tylko zmiany testowe bez cofania kodu?

Jeśli testy i kod są razem w jednej gałęzi — tak, można cofać rewizje. Ale lepiej unikać "cofania" testów bez kodu: pogarsza to jakość weryfikacji.

Typowe błędy i antywzorce

Przechowywanie testów nie w git, a w systemach plikowych
Prowadzenie testów w oddzielnym repozytorium bez wyraźnego powiązania z projektem
Dodawanie testów z zewnątrz (post factum), a nie równocześnie z kodem

Przykład z życia

Negatywny przypadek

Projekt z oddzielnym repozytorium testów automatycznych. Po wydaniu programiści "zapomnieli" zaktualizować testy — testy padały, przechodziły nieaktualne kontrole, błędy były wykrywane na produkcji.

Zalety:

Programiści mogli pracować niezależnie od QA

Wady:

Straty czasu na synchronizację, obecność "przestarzałych" testów

Pozytywny przypadek

Testy i kod projektu są prowadzone w jednej gałęzi git: przy każdym nowym pull request koniecznie aktualizowane są testy automatyczne dla dodanego kodu. Wszystkie zmiany przechodzą przegląd kodu i automatyczne kontrole.