dkarpele / async_api_sprint_2 Goto Github PK

ok

Проверить класс по работе с кешом на SOLID. Изменить структуру программы, если это необходимо.

Оценка: 5

Ссылка на PR: pass

С развитием проекта в тестах фикстур будет все больше и больше, и их нужно систематизировать. Можно вынести в отдельный файл (затем добавлять другие файлы, логически разделяя их) и тем самым облегчим conftest.py. Для этого есть pytest_plugins

Покрыть функциональными тестами endpoint /film

Оценка: 5

Проверить класс по работе с хранилищем на SOLID. Изменить структуру программы, если это необходимо.

Оценка: 5

Ссылка на PR: pass

В скриптах ожидания ES и Redis в тестах вместо вечного цикла, в который можно попасть при возникновении сложностей, лучше использовать backoff из прошлых спринтов. Он более функционален в сравнении с вечным циклом, теоретически он может сигнализировать команде поддержки после определенного количества попыток.

Функциональные тесты. Инфраструктура
Необходимо разработать инфраструктуру для запуска функциональных тестов. Тесты изолированно запускаются в docker-compose

Оценка: 13

Ссылка на PR: pass

Покрыть функциональными тестами endpoint /genre

Оценка: 5

Ссылка на PR: pass

Отличная работа! Вы мололцы! Предложения по доработке:

1. Не используйте прямое указание кодов ответов сервера в тестах (200, 400 и т.д.), применяйте http.HTTPStatus. Этим можно немного повысить читаемость кода https://docs.python.org/3/library/http.html#http.HTTPStatus
2. С развитием проекта в тестах фикстур будет все больше и больше, и их нужно систематизировать. Можно вынести в отдельный файл (затем добавлять другие файлы, логически разделяя их) и тем самым облегчим conftest.py. Для этого есть pytest_plugins
3. В скриптах ожидания ES и Redis в тестах вместо вечного цикла, в который можно попасть при возникновении сложностей, лучше использовать backoff из прошлых спринтов. Он более функционален в сравнении с вечным циклом, теоретически он может сигнализировать команде поддержки после определенного количества попыток.
4. [можно лучше] Рекомендую для всех тестов придерживаться подхода ААА. Т.е., делать перенос строки после каждой логической единицы, выполняемой в тесте, если тело теста превышает 3 строки. Под логическими единицами подразумевается: подготовка, вызов тестируемого объекта и сравнение результата теста (assert). Если в тесте меньше трех строк, то можно не делать переносы. https://freecontent.manning.com/making-better-unit-tests-part-1-the-aaa-pattern/
5. Этот маркер можно указать один раз на уровне файла: https://github.com/pytest-dev/pytest-asyncio/releases/tag/v0.20.2/
6. Если у вас в теле теста есть хотя бы один if, то вы запихнули в один тест несколько кейсов. Так делать нельзя, идея теста в том, что простой линейный код тестирует сложный, так достигается некоторый уровень надежности. if и другие конструкции в теле теста усложняют его и в итоге вы на сложный код пишите сложный тест, который потом еще раз другим тестом придется покрывать :) В общем, разделите все тесты, в которых у вас есть if на несколько таким образом, чтобы у вас не осталось ни одного if в теле тестов

Покрыть функциональными тестами endpoint /person

Оценка: 5

Ссылка на PR: pass

That's why sorting with redis doesn't work.

1. http://0.0.0.0:8000/api/v1/films/?sort=imdb_rating
   ES returns values sorted correctly.
2. Execute the same request the second time. Data returns from redis
   http://0.0.0.0:8000/api/v1/films/?sort=imdb_rating
   Data is unsorted.

await self.redis.hset(name=key, mapping=entities_dict)

saves dict as unsorted

I see 2 ways how to solve it:

1. Sort values manually if sort was provided in _get_from_cache after data = await self.redis.hgetall(name)

2. Try to use ZADD
   https://www.tutorialspoint.com/redis/redis_sorted_sets.htm

!NB! Fix the test TestFilmsSortRedis.test_get_from_redis

[можно лучше] Рекомендую для всех тестов придерживаться подхода ААА. Т.е., делать перенос строки после каждой логической единицы, выполняемой в тесте, если тело теста превышает 3 строки. Под логическими единицами подразумевается: подготовка, вызов тестируемого объекта и сравнение результата теста (assert). Если в тесте меньше трех строк, то можно не делать переносы.

Этот маркер можно указать один раз на уровне файла: https://github.com/pytest-dev/pytest-asyncio/releases/tag/v0.20.2/

Не используйте прямое указание кодов ответов сервера в тестах (200, 400 и т.д.), применяйте http.HTTPStatus. Этим можно немного повысить читаемость кода https://docs.python.org/3/library/http.html#http.HTTPStatus

Если у вас в теле теста есть хотя бы один if, то вы запихнули в один тест несколько кейсов. Так делать нельзя, идея теста в том, что простой линейный код тестирует сложный, так достигается некоторый уровень надежности. if и другие конструкции в теле теста усложняют его и в итоге вы на сложный код пишите сложный тест, который потом еще раз другим тестом придется покрывать :) В общем, разделите все тесты, в которых у вас есть if на несколько таким образом, чтобы у вас не осталось ни одного if в теле тестов