Ты не доверяешь принту в питоне или что?

Или ты не особо понимаешь что такое юниттест

=))) это мини апп. Есть менюшка, юзер может что-то туда запостить, что-то вывести себе на экран. Конкретно эта функция берет данные обьекта в которое юзер их может закинуть и выводит в консоль. Я не совсем правильно сказал - это по сути уже проверка системы, но мне ново именно получение данных из консоли. И мне нужно написать на это дело тест, что берёт нужные данные и выводит их в консоль. )

Так несколько понятнее, но имхо ты изначально что то делаешь не так. Если ты пишешь юниты то ты не должен проверять что выводится в консоль. Проверяй конкретную логику и конкретные значения.

Если ты пишешь функциональные тесты на консольную аппку и в обязательные проверки входит то что оно печатает в аутпут то заворачивай аутпут своей аппки в файловые дескрипторы, гугли операторы ввода вывода итд. И уже потом читай из файлового дескриптора

Спасибо, пошел дальше разбираться

а подскажи, что за курс?

zheka у тебя есть такой?

Если у тебя есть варианты представления (консоль, отправка в мессенджер и.т.д.), то ты на каждый такой тип делаешь сериализатор твоего объекта и сравниваешь готовую строку с ожидаемой, в зависимости от типа доставки до пользователя. Это ничем не отличается от юниттеста на любой другой метод класса.

Если хочешь прям проверить, что вывелось именно в том формате, что надо, тогда вызывай в тесте своё приложение с перенаправление stdout в файл. И потом его содержимое сравнивай с эталоном. Но это уже совсем не юнит.

Я пока в это дело только погружаюсь и неправильно понял лектора - задача была просто проверить ассертом, что функция вызывается оба раза с экспектед данными - одни данные из аппы, одни данные из тестового шаблона. Проверка через функцию patch замокав функцию print.

Даже не могу представить себе ситуацию где это может пригодиться

Для понимания общей картинки скорее всего. Скажем я теперь уже чуть вьехал, что такое mock

Лучше бы http мок какой попробовал

Я тебе расскажу. Когда дизайн приложения плохой, а тестировать надо. Условно, у тебя должен быть класс, который имеет публичные интерфейсы, ты их тестируешь и проверяешь, что эти методы тебе возвращают, что должны. И плевать на остальные внутренности этого класса, пока работает. Тогда классические ассерты помогут.

А бывает, что метод этого класса какую-то логику делает, а потом не возвращает тебе результат, а вызывает ещё какой-то более глубокий метод уже у другого класса. Делегирование в плохом смысле этого слова. И тогда ты можешь только замокать ту финальную функцию и проверить, что она вызывается с теми параметрами, которые ты считаешь верным результатом работы логики тестируемого объекта.

И типа финальная функция это принт?

Ну короче это и так понятно, но это уже не совсем уровень тестирования тестировщиками

Имхо

В этом случае да. Ну то есть, я бы сделал метод, который вернёт подготовленный текст, а потом бы его вывел. И метод бы можно было затестировать. А если выводит он сам, а возвращает хуй, то да. Мокаешь принт и ассертишь аргумент.

К слову, юниты не для тестировщиков, имхо.