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