Привествую.
Народ, а после того как в phpunit выпилили из коробки тестирование закрытых и защищенных свойств, как вы их тестируете?
Просто реально, публик св-в вообще не рекомендуют иметь, геттеры заводить на все тоже странно.
Открываешь этим реализацию.Код (Text):
Как же протестировать someChangeForX , всю его логику, если с чем assert делать, а не с чем.
Вроде ж по науке — «Модульное тестирование — это процесс тестирования наименьшей функциональной единицы кода.(с)». Мне именно код надо протестировать, а не открытое апи обьекта.
Те же protected методы протестить тоже надо, когда в них работа то делается…Самому открывать рефлексией, не покажется ли это говноподходом?
Предложу юзать предыдущую версию phpunit’а и развязать дискуссию с Бергманом, в последней поучаствую.
В своё время начирикал систему событий за зарплату, спустя несколько лет переиспользовал в своём пет-проекте, где было время покрыть код тестами, оказалось — пипец, нашёл кейс, где глючит, потому надо оставлять максимальные возможности для покрытия этими самыми тестами )
Да я уже начитался всех этих дискуссий, вижу что они жестко против этого. Даже не воспринимают что protected — это такое же АПИ, только потомкам.
Какой то у них другой по логике подход. Нужно время на обмыслить.
Раньше говорили что если вы сидите и в ручную тестируете свой код, что он рабочий, то не делайте так, а напишите тест.
А эти утверждают что надо модульным тестировать просто ожидаемое поведение обьекта…
И доставать инфу о нем только снаружи или моками.
Хотя например если в обьекте идут ряды всяких вычислений, а наружу он светит только метод выполнить() , то что теперь, не тестировать его внутряки?..
— Добавлено —
Старые версии не нужны, есть расширение полифилл, с трейтом нужным
Благими намерениями вымощена дорога в ад. Идея вроде бы хорошая, но реально родили трудности на ровном месте.