Какой стратегии придерживаться при тестировании изменений в приложении?

Да ты послушай, какая ебаная наука развернулась! Тестирование изменений, блядь. Это ж не просто ткнуть кнопку и посмотреть, не сдохло ли всё. Это целая стратегия, как партизанский отряд в тылу врага, только враг — это твой же код, который норовит нахуй сломаться в самый неподходящий момент.

Многоуровневая стратегия, или как не облажаться по полной:

1. Дымовое тестирование (Smoke Testing):

   • Это как сунуть палец в розетку, чтобы проверить, есть ли ток. Быстро, дерзко, по-хулигански. Собрали билд — запустили пару ключевых сценариев. Если не взорвалось и не задымилось — можно уже не бздеть и копать глубже.

2. Тестирование новой функциональности:

   • Вот тут уже включаем мозг, если он, конечно, не уснул. Берём требования, которые писал какой-нибудь полупидор из продактов, и начинаем проверять: а работает ли оно так, как он нарисовал в своей красивой презентации? Плюс ко всему, пытаемся сломать эту новую фичу всеми доступными способами. Вводим буквы вместо цифр, отрицательные числа, овердохуища символов. Наше дело — провоцировать.

3. Регрессионное тестирование (Regression Testing):

   • А вот это, сука, святое. Ты там одну кнопку передвинул, а у тебя в другом конце системы календарь перестал работать. Волнение ебать! Поэтому дёргаем за все ниточки в тех местах, которые могли зацепить наши правки. Если есть автотесты — запускаем пачку, молимся и пьём кофе.

4. Санитарное тестирование (Sanity Testing):

   • Ну, типа, после всех этих танцев с бубнами, ты возвращаешься к тому, что собственно и чинил. Исправил баг с отправкой письма? Так давай, сука, именно отправку письма и проверь ещё раз, досконально. Не отвлекаясь на ебушки-воробушки.

На чём мозги надо сломать в первую очередь:

• Обратная совместимость: Это когда ты выпускаешь новую версию API, а старые клиенты, которые как проклятые всё ещё используют v1, не должны посылать тебя нахуй. Версионирование, блядь, наш лучший друг.
• Миграция данных: О, это пиздец. Меняешь структуру базы — готовься к тому, что твои скрипты миграции могут превратить пользовательские «Ивановы» в красивые «NULL’ы». Тестировать надо на копии продовой базы, иначе терпения ноль ебать.
• Интеграция: Твой модуль не живёт в вакууме. Он общается с другими сервисами. Изменил формат запроса? Убедись, что соседний сервис не начал материться в логах.
• Производительность: Сделал «оптимизацию», а отклик вырос с 100 мс до 2 секунд? Поздравляю, ты мудак. Замеряй всегда.

Вот, смотри, как регрессию для API прикрутить, чтобы старые клиенты не выли:

import requests
import pytest

# Тест проверяет, что старый эндпоинт (v1) все еще работает,
# а новый (v2) возвращает ожидаемую новую структуру.

def test_backward_compatibility():
    # Старый клиент
    response_v1 = requests.get('https://api.example.com/v1/users/1')
    assert response_v1.status_code == 200
    assert 'name' in response_v1.json()  # Старое поле

def test_new_functionality():
    # Новый клиент
    response_v2 = requests.get('https://api.example.com/v2/users/1')
    assert response_v2.status_code == 200
    assert 'full_name' in response_v2.json()  # Новое поле
    assert 'avatar_url' in response_v2.json() # Новое поле

А если что-то пошло не так — всё в баг-трекер. Чётко, по шагам: «Сделал раз, сделал два — получил в глаз». Чтобы любой другой тестировщик или разработчик мог взять и воспроизвести этот цирк. Без этого — нихуя не выйдет, одни разговоры.