1. Интерфейсы, в общем то, скрывают класс, реализующий функционал.

Но, могу ли я в unit test'е проверить, что под интерфейсом скрывается реальный класс ?
Я ведь должен убедится, что фабрика создала мне именно нужный класс ?

Думаю, что в тесте делать проверку интерфейса на определенный тип - нормально.
Или нет ?

2. Правильно ли я понимаю, что тестируя некий метод, мы должны в тесте сравнивать результат тестируемой функции с жестко заданным-расчитанным числом.

Т.е. что мол, при вызове такой то функции с такими параметрами, мы должны получить 2342354234.3434 и все.
Никаких алгоритмов в тесте быть не должно. А иначе, если мы допустим баг в этом самом алгоритме, то тест будет сам багнутым, и будет выдавать красный свет, там где реальный код все рпавильно делает !
Т.е. я так понимаю, что тестируя каждый методы мы должны сами, в ручную, на калькуляторе посчитать все по формулам и уже в тест вставить готовое число результата на сравнение ?

bazileСпиридончик,

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

2. Если бы в тестах нельзя было бы писать свою логику, то толку от них было бы мало.


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

2. Я не против логики как таковой.
Мне кажется в тестах не должно быть логики, дублирующей, по сути, промышленный код.
Не должно быть такого:
- Вызываем функцию, и асертим ее по формуле: берем первое число, прибавляем второе, делим на третье, и если результат больше 100, то прибавить 50 .

Вот этого самого "берем первое число, умножаем на второе" в тесте быть не должно!
А должно быть просто:
Вызываем функцию с такими параметрами. Асертим, что она вернула строго конкретное число )которые мы высчитали на калькуляторе, ручками следуя той логике, которую должна пройти функция.

Иначе во первых у нас просто получится дублирование кода. Что в промышленном коде, что в тесте у нас будет абсолютно идентичная формула. Так, что тест по сути будет выглядеть как 5*3=3*5.

А во вторых, алгоритм подвержен багам. Ошибившись в тесте усложним себе жизнь в будущем, когда тест будет гореть красным при правильном промышленном коде.

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

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

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