AlekseyLobanov
(Migrated from github.com)
left a comment
Copy Link
Copy Source
В целом, ок.
Файл с тестами лучше разделить на 2: списки и элементы списков.
Один метод для тестирования лучше разделить на несколько с одной задачей, но желательно так, чтобы он всё равно всё покрывали.
Нужна команда для запуска тестов. Как ты это делала?
Будет здорово, если будет выводиться coverage. Для pytest есть простые интеграции.
В целом, ок.
1. Файл с тестами лучше разделить на 2: списки и элементы списков.
2. Один метод для тестирования лучше разделить на несколько с одной задачей, но желательно так, чтобы он всё равно всё покрывали.
3. Нужна команда для запуска тестов. Как ты это делала?
4. Будет здорово, если будет выводиться coverage. Для pytest есть простые интеграции.
Тут желательно проверить предусловие, а потом постусловие:
Сначала проверить, что объект есть
Потом проверить, что объект удалился (204) и его нет.
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
В целом, ок.
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась