Тесты - это зло. Когда я привык их иметь, я отвык думать. Понятия подменились, и вместо того, чтобы стремиться к правильной программе, я стремлюсь к зеленым тестам. При этом я, конечно, стремлюсь и к хорошему покрытию программы этими тестами, что в сумме дает вроде как то, что и надо. Но все равно ощущения странные.
Поскольку тесты обычно есть, я не боюсь ничего менять, надеясь на них. Когда покрытие хорошее, это еще может сойти с рук, а вот когда оно хромает, это фатально. Могу случайно сломать что-нибудь совсем, даже не заметив. Потом, когда до меня это доходит, понимаю, что если б я хоть чуть-чуть подумал, ничего бы не случилось.
Причем когда из-за моих изменений ломается что-нибудь незатестрированное в чужом коде, я даже не испытываю мук совести.
Но только благодаря наличию тестов (имхо) в Идее можно после каждого релиза все переписывать, надеясь на лучшее. И вообще, тесты - это хорошо. Значит, следуя классическому рецепту, перед изменением мира надо изменить себя. Например, научиться иногда думать. Хоть это и сабж.
4 comments:
Я тесты пишу Test Last, несмотря на то, что гуры рекомендуют писать Test First.
Проблема думанья в данном случае решается. Ты пишешь код, проверяешь его руками, и пишешь тесты, в надежде найти в нем баги.
Правда, Test First я не пешу, не по этой причине, а потому что на переключение между тестированием и кодированием уходит слишком много времени, и раздражает голову.
Кстати, рекомендую хорошую книжку про прагматичное тестирование: тут я про нее писал http://krlz.livejournal.com/59641.html?mode=reply
Она у нас в офисе в книжному шкафу валяеется.
У нас в Идее большая часть тестов имеет четко определенный и простой стиль оформления (файл до, действие, файл после), и на такие тесты отвлекаться приходится по минимуму (если он не первый в тесткейзе). Так что пишу я Test-Along чаще всего.
А баги в коде все равно ищутся обычно руками, и после этого иногда даже фиксируются в тестах. Хотя когда код уже есть, силен соблазн просто взять все и пофиксить, пока никто не заметил.
Книжку посмотрю, спасибо. Хотя бумажные книги много места занимают.
А ну понятн. А нет такого что компонента пишется отдельно, без лишних зависимостей на ядро чтобы тестировать? Имхо без этого нельзя написать тесты, которые работают реально быстро.
У нас в MPS тесты тоже не очень unit. Основное это тесты на генерацию, мы просто генерим все что только можно, и если не генериться, или генерится но не компилируются, они считаются сломавшимися. И это очень хорошо работает. После таких нововведений, стабильность мпс резко возврасла.
Я начал пару месяцев назад, писать unit-тесты test last, прочитав эту книжку, и это сработало. Если компонента зависит от ядра через уровень абстракции, и может очень быстро протестироваться, то это оправдывает себя.
Независимые компоненты попадаются, но редко. А так все идейские тесты поднимаются жуть как долго, поэтому там самое важное между ними в статике еще и расшаривается, чем обеспечиваются надежные сайд-эффекты. Зато тормозит только первый тест, остальные обычно идут меньше секунды (да, тоже отстой, а что делать). Пытался я одно время писать тесты, в которых поднимать руками не всю Идею, а только нужные мне компоненты, а потом начались великие переделки, и оказалось, что эти тесты надо с каждым изменением API подпатчивать, так что я постепенно от них избавляюсь.
Post a Comment