Tests #24
@@ -11,17 +11,28 @@ from rest_framework.test import APITestCase
|
|||||||
|
|
|||||||
from rest_framework.test import APIClient
|
from rest_framework.test import APIClient
|
||||||
from django.contrib.auth.models import User
|
from django.contrib.auth.models import User
|
||||||
from backend.api import router
|
from backend.api import router
|
||||||
|
from collections import OrderedDict
|
||||||
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
|||||||
|
|
||||||
class EasyTest(APITestCase):
|
class EasyTest(APITestCase):
|
||||||
|
|
||||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
|||||||
def test_list(self):
|
def test_list(self):
|
||||||
"""
|
"""
|
||||||
The first test.
|
The first test.
|
||||||
"""
|
"""
|
||||||
user = User.objects.create_user('test_user', 'test@test.com', 'test_password')
|
user = User.objects.create_user('test_user', 'test@test.com', 'test_password')
|
||||||
|
url = reverse('ToDoLists-list')
|
||||||
|
Лучше разбить на 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)
|
self.client.force_authenticate(user=user)
|
||||||
response = self.client.get(url, data, format='json')
|
|
||||||
|
Лучше разбить на 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
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
|||||||
|
response = self.client.get(url, {}, format='json')
|
||||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
|||||||
self.assertEqual(response.status_code, status.HTTP_200_OK)
|
self.assertEqual(response.status_code, status.HTTP_200_OK)
|
||||||
self.assertEqual(response.data, [])
|
self.assertEqual(response.data, OrderedDict([('count', 0), ('next', None), ('previous', None), ('results', [])]))
|
||||||
|
Лучше разбить на 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
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
|||||||
|
|
||||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
|||||||
|
response = self.client.post(url, {"title": "ToDoList1"}, format='json')
|
||||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
|||||||
|
self.assertEqual(response.status_code, status.HTTP_201_CREATED)
|
||||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
|||||||
|
self.assertEqual(response.data['title'], "ToDoList1")
|
||||||
|
Лучше разбить на 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
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
|||||||
|
response = self.client.get(url, {}, 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
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
|||||||
|
|
||||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
|||||||
|
self.assertEqual((response.data['count'], response.data['next'], response.data['previous'], \
|
||||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
|||||||
|
response.data['results'][0]['title']), (1, None, None, "ToDoList1"))
|
||||||
|
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
1. Сначала проверить, что объект есть
2. Потом проверить, что объект удалился (204) и его нет.
Тоже лучше много проверок, чем одна сложная Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Порядок импортов принят таким:
1. Python модули
2. Библиотеки
3. Пользовательские модули.
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
|
|||||||
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Лучше разбить на 3 проверки, т.к. тогда при фейле сообщение будет более информативным
Тут желательно проверить предусловие, а потом постусловие:
Тут желательно проверить предусловие, а потом постусловие:
Тоже лучше много проверок, чем одна сложная
Тоже лучше много проверок, чем одна сложная
Порядок импортов принят таким:
Т.е. collections -> django -> backend.api
Порядок импортов принят таким:
Т.е. collections -> django -> backend.api
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Вот этот вызов выглядит очень непонятно. Лучше использовать именованные переменные, мне кажется
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась
Может быть можно этот кейс разбить на несколько более простых: типа просто проверка, что всё ок, проверка, что создание + модификация ок, разные элементы создаются и т.п. Сейчас падение этого теста просто показывает, что что-то сломалось, а несколько тестов показали бы, какая именно часть логики сломалась