Привествую. Народ, а после того как в phpunit выпилили из коробки тестирование закрытых и защищенных свойств, как вы их тестируете? Просто реально, публик св-в вообще не рекомендуют иметь, геттеры заводить на все тоже странно. Открываешь этим реализацию. Код (Text): class XXX { protected $x; public someChangeForX($strategy) {...} } Как же протестировать someChangeForX , всю его логику, если с чем assert делать, а не с чем. Вроде ж по науке - "Модульное тестирование — это процесс тестирования наименьшей функциональной единицы кода.(с)". Мне именно код надо протестировать, а не открытое апи обьекта. Те же protected методы протестить тоже надо, когда в них работа то делается... Самому открывать рефлексией, не покажется ли это говноподходом?
Предложу юзать предыдущую версию phpunit'а и развязать дискуссию с Бергманом, в последней поучаствую.
В своё время начирикал систему событий за зарплату, спустя несколько лет переиспользовал в своём пет-проекте, где было время покрыть код тестами, оказалось -- пипец, нашёл кейс, где глючит, потому надо оставлять максимальные возможности для покрытия этими самыми тестами )
Да я уже начитался всех этих дискуссий, вижу что они жестко против этого. Даже не воспринимают что protected - это такое же АПИ, только потомкам. Какой то у них другой по логике подход. Нужно время на обмыслить. Раньше говорили что если вы сидите и в ручную тестируете свой код, что он рабочий, то не делайте так, а напишите тест. А эти утверждают что надо модульным тестировать просто ожидаемое поведение обьекта... И доставать инфу о нем только снаружи или моками. Хотя например если в обьекте идут ряды всяких вычислений, а наружу он светит только метод выполнить() , то что теперь, не тестировать его внутряки?.. --- Добавлено --- Старые версии не нужны, есть расширение полифилл, с трейтом нужным
Благими намерениями вымощена дорога в ад. Идея вроде бы хорошая, но реально родили трудности на ровном месте.