Statyczna weryfikacja kodu służy do sprawdzenia, czy kod spełnia określone standardy jakości. Wszystkie statyczne kontrole kodu można przeprowadzić za pomocą frameworka pre-commit.
Sprawdzenia pre-commit wykonują całą niezbędną instalację, gdy uruchamiasz je po raz pierwszy.
Pre-commit hooki pomagają przyspieszyć lokalny cykl rozwoju i zmniejszyć obciążenie infrastruktury CI. Rozważ zainstalowanie narzędzia pre-commit, aby uruchamiał się automatycznie dla każdego commita.
Pre-commit hooki domyślnie sprawdzają tylko pliki, nad którymi aktualnie pracujesz, co czynni je szybkimi. Każdy hook jest instalowany w osobnym śroodowisku niezależnym od systemu, a więc może być pewien, że sprawdzenia wykonane lokalne powiodą się również na środowisku CI.
Zintegrowaliśmy fantastyczne ramy pre-commit w naszym przepływie pracy programistycznej. Aby go zainstalować i używać, potrzebujesz lokalnie przynajmniej Pythona 3.6.
Aby zainstalować pre-commit uruchom:
pip install pre-commit
pre-commit installPo instalacji, podpięcia pre-commit są uruchamiane automatycznie podczas tworzenia commitów i będą działać tylko na plikach, które zmienisz w ostatnim commicie, więc zwykle są dość szybkie i nie spowalniają iteracji. Istnieją również sposoby, aby tymczasowo wyłączyć wstępne zatwierdzanie, gdy zatwierdzasz kod za pomocą przełącznika --no-verify lub pomijasz pewne sprawdzenia, które mogą znacznie zakłócać pracę.
Aby włączyć sprawdzanie przed zatwierdzeniem podczas tworzenia commitów w git, wpisz:
pre-commit installAby zainstalować czeki również dla operacji pre-push, wprowadź:
pre-commit install -t pre-pushAby uzyskać szczegółowe informacje na temat zaawansowanych technik instalacji, uruchom:
pre-commit install --helpWyłączanie poszczególnych hooków
Jeśli masz problem z uruchomieniem konkretnego hooka, to możesz wyłączyć je tymczasowo. Aby to zrobić ty musisz ustawić zmienną środowiskową SKIP na listę oddzielonych przecinkami hooków do pominięcia. Na przykład, jeśli chcesz pominąć sortowanie definicji importów, powinieneś być w stanie to zrobić, ustawiając export SKIP=isort. Możesz również dodać to do swojego .bashrc lub .zshrc, jeśli nie chcesz ustawiać go ręcznie za każdym razem, gdy wchodzisz do terminala.
Po instalacji, hooki pre-commit są tworzone automatycznie, gdy tworzysz commit, ale ty możesz je również uruchamiac manualnie, jesli potrzebujesz.
Uruchom wszystkie kontrole plików umieszczonych w poczekalni (ang. staged files):
pre-commit run
Uruchom tylko sprawdzenie
isortna plikach w poczelni:pre-commit run isort
Uruchom tylko sprawdzenie
isortna wszystkich plikach:pre-commit run isort --all-files
Uruchom wszystkie sprawdzenia na wszystkich plikach:
pre-commit run --all-files
Uruchom wszystkie sprawdzenia tylko na plikach zmodyfikowanych w ostatnim dostępnym lokalnie commit w aktualnej gałęzi:
pre-commit run --source=HEAD^ --origin=HEAD
Pomiń jedno lub więcej sprawdzeń, określając listę sprawdzeń oddzielonych przecinkami do pominięcia w zmiennej
SKIP:SKIP=mypy,flake8,build pre-commit run --all-files
Zawsze możesz pominąć uruchamianie testów, podając flagę --no-verify w poleceniu git commit.
Po więcej informacji na temat użycia hooków pre-commit, zobacz Witryna Pre-commit.
Kod logiki jest automatycznie testowny z uyciem pytest . Wszystkie testy znajduja się w katalogach: pola/*/tests lub plikach pola/*/tests.py.
Aby uruchomić wszystkie test uruchom:
docker compose run --rm web pytestMożesz określić poszczególne testy do uruchomienia, dostarczając dowolną liczbę „etykiet testowych” do komendy ./manage.py. Każda etykieta testowa może być pełną kropkowaną ścieżką Pythona do pakietu, modułu, podklasy TestCase lub metody testowej. Na przykład:
# Uruchamia wszystkie testy znalezione w pakiecie pola.company
docker compose run --rm web pytest pola/company
# Uruchom tylko jeden test case
docker compose run --rm web pytest pola/tests/test_views.py -k TestFrontPageView
# Uruchamia tylko jedna metode testową
docker compose run --rm web pytest pola/tests/test_views.py -k TestFrontPageView -k test_template_usedWięcej informacji na temat tesotwnia dostępna jest w dokumenttacji Djangoo: Testing in Django.
Jeśli wprowadzane są większe zmiany w bazie danych warto wykonać próbe wykorzystujać kopie bazy danych.
W tym celu uruchom przepływ pracy o nazwie "Migration validation" na Github Action korzystając z twojej gałęzi.
Nie jest wspieranie testowania migracji dla pull-requestów z forków. Kod musi być w naszym repozytorium.