Tests #24
1
.gitignore
vendored
@@ -65,6 +65,5 @@ target/
|
||||
*.jsl
|
||||
*.db
|
||||
tmp*
|
||||
test_*
|
||||
.env*
|
||||
venv*
|
||||
|
||||
0
backend/tests/__init__.py
Normal file
27
backend/tests/test_1.py
Normal file
@@ -0,0 +1,27 @@
|
||||
|
|
||||
import os
|
||||
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "backend.settings")
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
from django.core.wsgi import get_wsgi_application
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
application = get_wsgi_application()
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
from django.urls import reverse
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
from rest_framework import status
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
from rest_framework.test import APITestCase
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
from rest_framework.test import APIClient
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
from django.contrib.auth.models import User
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
from backend.api import router
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
class EasyTest(APITestCase):
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
def test_list(self):
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
"""
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
The first test.
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
"""
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
user = User.objects.create_user('test_user', 'test@test.com', 'test_password')
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
url = reverse('ToDoLists-list')#reverse('ToDoLists-list')
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
data = {}
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
self.client.force_authenticate(user=user)
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
response = self.client.get(url, data, format='json')
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
self.assertEqual(response.status_code, status.HTTP_200_OK)
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
self.assertEqual(response.data, [])
|
||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
||||
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
Тоже лучше много проверок, чем одна сложная
Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Т.е. collections -> django -> backend.api
Порядок импортов принят таким:
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась