paladin223 / django

0 stars 0 forks source link

Больше тестов богу тестов! #17

Closed drowsycoder closed 1 year ago

drowsycoder commented 1 year ago

Тот момент, когда можно залезть чуть в проверку допника ещё на этапе проверки основного задания

Проверок эндпоинтов для приложения catalog мало Для основной проверки и проверки регулярки (которую посмотрю в рамках допника) можно продублировать один и тот же набор проверяемых случаев Давай проверим 0, 1, 01, 010, 10, 100, отрицательный ноль, отрицательное число, десятичную дробь, смесь из цифр и букв (когда цифры вначале, в середине, в конце, по краям), строки с некоторыми спецсимволами (типа $, %, ^..., но не теми, что для параметризации урла используются или для установки якоря)

На перспективу сдачи допников подумать, что можно улучшить в тестах

Почитать про сабтест в свободное время: https://www.caktusgroup.com/blog/2017/05/29/subtests-are-best/ https://docs.python.org/3/library/unittest.html#distinguishing-test-iterations-using-subtests

Или про @parameterized можно

Тестируем на корректное, тестируем на некорректное. Группируем, оптимизируем Возможно, останется только что-то типа набора

def test_catalog_endpoint()
def test_catalog_item_endpoint()
def test_catalog_item_positive_integer_endpoint()

Может быть ещё примерно одна отдельная функция

drowsycoder commented 1 year ago

Заранее скажу: если эндпоинты обрабатываются разными вьюхами, то и тесты на них должны располагаться в отдельных функциях

drowsycoder commented 1 year ago

К первому допнику — мастхев. Так-то уже должны быть нормальные

drowsycoder commented 1 year ago

Группируем, оптимизируем

Не учтено. Много фукций, которые можно объединить В качестве следующих ступенек для избавления от дублирования кода и оптимизации может быть группирование по тестируемому эндпоинту, внутри — по статус-коду, использование сабтест, использование parametrized

Но аккуратнее, переоптимизировать тесты, собрав все в одну функцию, тоже будет плохим путём Корень /catalog/ не трогай, с тестом там норм. Остальные - проработать

Почему просил проверить, например, 010? Где-то по логике условия задания не должен проходить ведущий ноль Почему 10? Проблему завешающего нуля, зависящего от необходимости в каких-то случаях не пропускать 0. Будь регулярка наспех написана как [1-9]* (ну, со всеми соседними символами) — она бы приняла 9 или 11, но споткнулась бы на числах 10 или 20 И так далее. Я же не просто так эти примеры привёл

    def test_catalog_str(self):
        response = Client().get("/catalog/ooo")
        self.assertNotEqual(response.status_code, HTTPStatus.OK)

— плохая проверка. Давай вернём в урл забытый слэш и протестируем чётко на 404 Кстати, обрати внимание снова. Какой статус мы бы получили, если бы там было валидное число? Там же забыт trailing slash, а значит, вместо 200 нам прилетит 301. На таких мелочах потом много нервов можно потерять