и тут получается что если делать подобного рода мини функции, которые смысла почти не несут, то надо доку ментировать их да еще и тестировать. по моему куча лишних телодвижений
по TDD, документация вообще должна быть в процессе разработки, т.е. когда уже все отлажено, так как одна функция в процессе может мигрировать из класса в класс. Документировать желательно только public, ибо вспомогательные функции не имеет смысла документировать.
телодвижения ни когда не бывают лишними, все имеет смысл, но подход в моем последнем примере, наиболее правильный.
Опять, применяя в TDD, такой подход, как
PHP:
$cat->getParentId(1);
$this->assertEqual( $cat->sql , "SELECT ... = 1");
мы всегда имеем большую вероятность нарваться на FAILTURE из-за какого-нибудь пропущенного пробела или иного знака, кавычки или еще чего-нибудь. В этом случае, лично для меня - наиболее простой способ отладки или отлова неприятностей - проще визуально работать с SQL.
по этому TDD применительно к отладке текстового представления запроса - не всегда рационально.
вот для этого примера, то что надо.
Код:
$cat->getParentId(1);
$this->assertEqual( $cat->getGoodName , "Пила электрическая модель UL-152")