попробуй почитать туториалы по simpletest - там, мне кажется, доходчивее
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
TDD кто сможет поучить?
- Автор темы craz
- Дата начала
и TDD - это не когда "надо протестировать функции", а когда ты начинаешь проектирование архитектуры с написания тестов.
смысл в том, что если что-то тяжело протестировать, значит этим будет и пользоваться непросто
в твоем примере какое-то странное апи, сложно понять зачем снаружи все эти isFileCss нужны
смысл в том, что если что-то тяжело протестировать, значит этим будет и пользоваться непросто
в твоем примере какое-то странное апи, сложно понять зачем снаружи все эти isFileCss нужны
craz
Нестандартное звание
Ну я же про это!!!
Я про то как написать этот первый тест? с чего начинать...
Блин столько времени был в собственном бане, а так и не научился передавать свои мысли?(((
craz
Нестандартное звание
craz
Нестандартное звание
Вот и я про тоже!
Ладно я завтра сяду понапишу уже что-то что можно будет обсуждать. Буду надеяться что энтузиазма хватит у кого-нибудь хотя бы глянуть.
craz
Нестандартное звание
короче надо набирать группу для штудирования)
craz
Нестандартное звание
ага... http://detkam.e-papa.ru/mp/15/17.htmlcraz
ты бы мог уже нормально в тестах подразобраться чем тут сидеть, но нет, куда же мы без зондер команды
Блин ну некогда было эти два дня и я реально был ориентирован на ответы, а не на флуд...)
Сам флудер, сам нифига не делаю, но все таки надеюсь - оптимист чтоль...
И вообще, чем плохо что нас рать?)))
Короче надо приступать уже, я думаю.
Поэтому повестка дня: Что будем писать?
"Многие программисты, однажды попробовав работать в стиле TDD, сталкиваются с многочисленными проблемами и бросают тестирование. Они отмечают, что модульное тестирование усложняет процесс разработки, делает его слишком медленным и более трудоемким из-за возрастающего объема тестового кода, который слишком сложно поддерживать. Общаясь с такими разработчиками, мы заметили, что они все сталкиваются с похожими проблемами и делают одни и те же ошибки. Но, как правило, во всем они винят именно тесты. " (c)
craz
такс. я так понимаю, проблема номер один - ты смешал тестирование и TDD. TDD - это когда сразу пигется тест, затем код. Я только что понял, что ты говоришь об обычном тестировании, тогда стоит начать с регресивного и писать тесты перед тем, как собираешься рефакторить или апдейтишь существующий функционал. Возьми кусок своего худшего кода, и начни писать на него юнит тест, каждый тест должен тестить только один метод одного класса. В этот момент тебе придётся много рефакторить. А дальше пойдёт как по накатонному.
На предыдущей работе последние 3 месяца мы только юнит тестами и занимались, так что я этого г...на наелся/ не очень люблю юнит тесты и покрываю ими только то,что кажется необходимым и в 99% пост факту, а не TDD. в то же время практически с начала карьеры практиковал написание wishlist, где сразу писал пример кода, а затем его реализовывал, до сих пор так делаю, а вот если пишу вначале тест, то сбиваюсь с мысли.
такс. я так понимаю, проблема номер один - ты смешал тестирование и TDD. TDD - это когда сразу пигется тест, затем код. Я только что понял, что ты говоришь об обычном тестировании, тогда стоит начать с регресивного и писать тесты перед тем, как собираешься рефакторить или апдейтишь существующий функционал. Возьми кусок своего худшего кода, и начни писать на него юнит тест, каждый тест должен тестить только один метод одного класса. В этот момент тебе придётся много рефакторить. А дальше пойдёт как по накатонному.
На предыдущей работе последние 3 месяца мы только юнит тестами и занимались, так что я этого г...на наелся/ не очень люблю юнит тесты и покрываю ими только то,что кажется необходимым и в 99% пост факту, а не TDD. в то же время практически с начала карьеры практиковал написание wishlist, где сразу писал пример кода, а затем его реализовывал, до сих пор так делаю, а вот если пишу вначале тест, то сбиваюсь с мысли.
craz
Нестандартное звание
Нет ты не правильно понял... С чего ты вообще решил? Мне именно TDD надо, ибо
Вот я как раз привел цитату с аджайлдева об этом. Получается что ты не сумел научиться их готовить?
Потому что как я понимаю данный скил позволяет писать только тот код который нужен - "принцип единой достаточности" - я бы его назвал.
По сути в идеале решение любой проблемы правильно представляет только один код)))))))) - надо понимать, что это ваааааааааще очень идеальный идеал)
craz
а, сорри, меня смутила последняя цитата из твоего предыдущего поста, показалось что она описывает обычное тестирования, т.к. там описаны проблемы обычного тестирования. У tdd как раз проблема что его сложно продумать заранее и приходится много раз возвращаться к тесту, ну и многословность теста, из-за которого сбивается мысль.
а, сорри, меня смутила последняя цитата из твоего предыдущего поста, показалось что она описывает обычное тестирования, т.к. там описаны проблемы обычного тестирования. У tdd как раз проблема что его сложно продумать заранее и приходится много раз возвращаться к тесту, ну и многословность теста, из-за которого сбивается мысль.
craz
Нестандартное звание
Почему многословность?
И как можно сбиться? Ты знаешь, что делает метод, пишешь чутка теста простейшего -> пишешь немного кода -> проходишь тест -> дописываешь следующие условия. -> код -> тест и т.д.
Ну, смотри, я обычно набрасываю такой список, прикинь сколько времени и кода нужно чтобы написать тест. Причём для теста нужно ещё моки наделать и в итоге получится кода гораздо больше чем вишлист+реализация.
Кстати,для селениума тесты из-за тойже причины пишу на ruby. так как он менее многословен.
PHP:
$obj = new DOMArray();
// простое убравнление элементами: вставка, удаление, замена
$obj->append($node, 'nodeName');
$obj->inserBefore('nodeName', $nodeBefore, 'nodeBeforeName');
$obj->inserAffter('nodeName', $nodeAffter, 'nodeAffterName');
$obj->insertAsFirst($firstName, 'firstNode');
$obj->insertAsLast($lastName, 'lastNode');
$obj->remove('nodeBeforeName');
$obj->replace('nodeName', $replaceNede);
// управление атрибутами
$obj->get('nodeName')->getAttribute('value');
$obj->get('nodeName')->setAttribute('attr_name', 'value');
$obj->get('nodeName')->removeAttribute('value');
$obj = new Model();
$form = $obj->getForm('add');
if ($this->getUser()->isRoot()) {
$form->get('submit')->setAttribute('title', 'Сохранить');
$form->insertBefore('submit', $fieldForRootOnly);
}разумеется. тестами надо покрывать то, что относится к framework core / application core
юнит тест на пейдж контроллер это смешно ей богу )
для тестирования юзкейсов есть функциональные/интеграционные тесты, это уже совсем другое
а мне нравится core штуки через тдд делать, помогает сразу построить удобное апи
модель отсюда нахер, проверяем экспортилку из obj
самбит чтоли тестировать? )
то что obj создает форму это как то странновато
а первую часть я сначала так и пишу, потом уже ассерты расставляю и дроблю - когда без них заработало
моки не люблю, в 95% случаев проще обойтись сеттерами на заглушки ручками писанные
их слишком долго писать, эти моки
хотя не исключаю что просто не умею