🐞 Как один тест помог найти баг в Django 6.0

Представьте: вы настроили идеальный конвейер. uv летает, Renovate тихонько обновляет зависимости в фоне, автомёрж работает, жизнь прекрасна.

💥 И тут прилетает Django 6.0. Один тест из всех падает.

Тест проверял ссылку с мульти-значениями в query-параметрах: /?content_type=1&content_type=2

Оказалось, что в Django 6.0 вместо этого стало рендериться: /?content_type=2 — выживало только последнее значение.

😡 Ребята хотели как лучше. В новой версии Django тег {% querystring %} научился принимать несколько позиционных аргументов. В ходе рефакторинга разработчики начали итерироваться по QueryDict.items(). Проблема в том, что .items() у QueryDict возвращает только последнее значение для каждого ключа.

Автор этой истории, мог бы просто ругаться на сырой релиз. Но его спас «правильно ленивый» тест, написанный ещё во времена Django 4.2.

Самое интересное здесь не сам баг, а то, как он был пойман:

1️⃣ Тест не вызывал метод модели напрямую, а проверял итоговый HTML через BeautifulSoup.

2️⃣ Когда-то в проекте был кастомный метод для формирования URL, который позже заменили на стандартный тег Django. Тест при этом не меняли — и он продолжил работать, проверяя именно то, что видит пользователь.

3️⃣ Если бы тест проверял только внутреннюю логику метода, он бы никогда не узнал, что обновление библиотеки сломало отображение на фронтенде.

💡 Выводы для нас:

➡️ Автоматизируйте апдейты: инструменты вроде Renovate превращают обновление в поток мелких правок, а не в «десантную операцию» раз в полгода.

➡️ Пишите «эмпатичные» тесты: тесты должны жить дольше, чем код, который они проверяют. Хороший тест фокусируется на поведении системы, а не на том, как вы назвали переменную.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека питониста

#буст