Comments 6
Тестирование состояния
Во многих случаях можно отдать предпочтение другим методам тестируемого объекта(как один из вариантов), и тогда детали реализации в тесте снова станут неизвестны.
Каким другим? Если верить рисунку, то вы предлагаете изменить поведение сервера, чтобы он на запрос стал отдавать некоторый статус записи в БД. Т. е. раньше клиент дёргает сервер, тот что-то пишет в БД и тест проверял запись в БД. Это понятный сценарий и только так и можно быть уверенным, что сервер сделал то, что от него ожидали. Вы же предлагаете изменить поведение сервера в угоду удобства тестирования? Или я вас неправильно понял?
Есть такой подход, когда мы проверяем состояние не с помощью деталей реализации, а с помощью уже имеющегося открытого API.
Вместо того, чтобы явно вызывать orm или sql запрос, чтобы проверить, что вы создали нужный объект, в тесте вам нужно дёрнуть метод get того же репозитория.
Этот подход при желании можно использовать даже при тестировании самого приложения. Сначала вы делаете test_client.save(path=..., ...), а на этапе проверки делаете test_client.get(path=..., ...)
Не совсем понял про "менять сервер в угоду тестов"
Если тест работал, а потом начал падать, значит тест работает. Кто-то влез в логику и сломал ее.
Я не совсем понимаю про что вы. Если результаты работы объекта не меняются, но тест падает, очень вероятно что ваш тест хрупкий, завязанный на детали реализации, и это ложное срабатывание так называемое.
Как правильно писать тесты? Часть 1