Собрали в одном месте самые важные ссылкичитайте нас в Twitter
Доклад поможет раскрыть несколько важных моментов, которые помогут написать тесты дешево, быстро и правильно: Общая архитектура приложения, при которой удобно использовать интеграционные тесты Общая архитектура тестов Использование pytest и mocker На реальном примере покроем приложение сначала юнит-тестами и убедимся, что такой подход к тестированию не совсем корректный и в итоге пропускает ошибки в функционале. Параллельно посмотрим, что наличие исключительно интеграционных тестов тоже несет не всегда позитивные последствия. На примере доклада рассмотрим подход к разработке, который находится между TDD и "разработал и после покрыл тестами". Помимо всего прочего, сможем посмотреть, как можно тестировать код на максимальную глубину, даже захватывая базовые классы Слушатели смогут убедиться, что высокий процент покрытия тестами — это не всегда хорошо. А так же смогут понять, что разработка и параллельное тестирование собственного кода — это сбалансированный подход в плане качества кода, стоимости разработки. Мы сможем посмотреть на реальном примере, что писать тесты с хорошей архитектурой не так сложно и долго.
Популярность Python продолжает расти, а значит, проекты, созданные на этом языке программирования, становятся все масштабнее и сложнее. Многие разработчики проявляют интерес к высокоуровневым паттернам проектирования, таким как чистая и событийно-управляемая архитектура и паттерны предметно-ориентированного проектирования (DDD). Но их адаптация под Python не всегда очевидна.
Очень часто можно услышать о методах тестирования, таких как TDD, и о том, как тестировать бизнес-логику приложения. Однако тестирование производительности приложения – это совсем другая задача. Есть много разных способов, но самым общим подходом считается создание среды, в которой можно проводить DDoS-атаку на свое приложение и наблюдать за его поведением. Это очень интересная тема, но это не то, о чем я хочу сегодня поговорить. Сегодня мы рассмотрим более простой тест, тот, который вы можете сделать с использованием юнит-тестов Django по умолчанию: то есть тестирование количество обращений вашего приложения к базе данных.
Речь пойдет о том, как мы поддерживаем здоровье кодовой базы в проекте с безумными требованиями к скорости и постоянно меняющимися задачами. Мы поговорим про TDD, SOLID и KISS там, где люди меньше всего к этому готовы — в стартапе, который доставляет стройматериалы
Медленные тесты не только тратят время разработчиков на ожидание, но и усложняют следование лучших практик TDD (red-green testing). Когда тестовый набор выполняется несколько минут или дольше - это приводит к тому, что весь набор тестов запускают редко и баги, которые можно было бы исправить раньше и быстрее, откладываются.
В этом посте я расскажу как ускорить тесты вашего Django приложения и рассмотрю, что убивает скорость ваших тестов. В качестве примера буду использовать простой набор тестов, который вы можете найти на GitHub.
Начнем с простого определения модели StorageRoom. Как было сказано ранее, модели в чистой архитектуре очень легкие, по крайней мере, легче, чем их ORM-аналоги в фреймворках. Раз мы следуем методологии TDD, то первое, что мы напишем, это тесты. Создадим файл tests/domain/test_storageroom.py и поместим внутри него этот код:
Flask – это замечательный микро веб фреймворк, основанный на Python. Flaskr – это миниблог, который описан в официальном руководстве по Flask. Я продирался через это руководство больше раз, чем могу в этом признаться. Тем не менее, я хотел бы взять это руководство для следующего шага, добавив в него разработку через тестирование (test driven development) и немножко jQuery.
Тестирование программ повышает уверенность в ее способности работать. Есть даже большие школы, которые говорят о тестах, например, TDD, BDD.
У ручных тестов есть недостаток, среди прочих - тесты пишет человек. В следствии этого - он не сможет проверить работу функции/класса/etc на всех данных. А когда нам быть уверенным что даже на самых невалидных данных работает корректно, то без случайных данных не обойтись.