ну так вы же не тестите + или *

класс эт черный ящик для теста. тест не должен проверять, что там класс внутри делает

вы тестите кейсы 2 2 = 4

ваш тест будет проверять типа входы 2 и 2 и выход 4. А потом 3 3 и выход ????

тесты ведь тоже можно писать как попало. Очень часто есть тесты которые не нужны вообще. Либо тесты которые не покрывают то что нужно было протестировать.

Да? Ну ладно. Пусть так будет.

Ладно , с вами весело, но меня ждет легаси ) Сам себя не отрефакторит.
Успехов вам в нелегком деле!

Ну философия с Unit тестированием именно такая. Это тоже самое что тестировать ли private методы? Вы тестируете их?

Скажите вы тестируется private методы? Нужно ли их тестировать?

ну это не я придумал. хотя вот читаю сейчас, что есть и white-box unit testing, но не совсем понимаю, что они тестируют и как это может выглядеть.

так можно и число тактов процессора тестировать

если это действительно важно, то че бы не протестить?

камон, мы же пишем на пшп

Ну в 8 можно же подрубать всякие коды на С ? если целью задаться думаю это возможно сделать, хоть и не нужно.

нет никакого white box unit testing. Это все заблуждения или там упрощения вида "если есть black box наверное должен быть white box". Ну или люди путают mockist tdd + constract testing с антипаттерном "тестирование деталей реализации". Это совсем разные вещи

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

юнит тесты это про дизайн системы, а не про "верификацию примеров". У людей проблемы с дизайном системы и как следствие выходят херовые/бесполезные тесты

это мнение должно чем-то подкрепляться. Например - есть фронтенд разработка где много зависимостей и в целом мало логики вокруг стэйт менеджмента. Есть Typescript какой который позволяет достаточно много из того что "раньше только юнитами закрывали" закрыть типами и статическим анализом. В итоге у тебя вместо "пирамиды тестирования" получается "трофей тестирования" (https://testingjavascript.com/)

есть понятие Return of investments для каждого из видов тестирования. Можно смотреть исходя из этого.

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

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

потому челы которые пишут какие-то сложные системы топят за Integration tests are scam а люди которые пилят чет типа инстаграма пишут о том что пирамида тестирования не актуальна. И те и те правы, просто у них разные обстоятельства.