Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
TDD хорошо когда есть четкое ТЗ и понимание что структура завтра не поменяется из-за изменившихся требований. Когда разработчик знает что «вот я щас напишу тесты, напишу код, всё заработает, и мне не надо будет это всё переделывать потом». К сожалению, реалии зачастую таковы, что клиент по ходу дела хочет то, хочет это, а потом так, сяк, и ещё эдак. И его не останавливает уже ПМовское «изменения > время > деньги». У него есть деньги, он хочет капризы. И когда 30-50% проекта переписывается, 15-25% codebase выбрасывается, а какой-то участок меняется уже четвертый раз, задумываешься — а стоит ли каждый раз писать тесты?.. В итоге примерно 15-20% времени разработчика улетает в пустоту. Коту под хвост. И опять, опять писать эти чёртовы тесты на эти чёртовы изменившиеся требования.
Разработка с TDD, как вы ожидаете это будет: написали тесты, написали код, выкатили, проверили, получили фидбек, утвердили, пошли дальше.
Как это есть на самом деле: написали тесты, написали код, выкатили, проверили, получили фидбек, не утвердили, переписали тесты, доправили код, повторили итерацию сначала ещё 2-4 раза.
Разработка code first: написали, выкатили, проверили, утвердили/не утвердили (и повторили 2 шага итерации), покрыли тестами, двинулись дальше.
Экономим время (но и хрен бы с ним), экономим нервы (а вот это уже ценно).
Не стоит считать что TDD — панацея. Стоит четко понимать, когда TDD стоит применять (четкое, неизменное ТЗ), а когда это просто не выгодно и безсмысленно. В частности в гибком и часто меняемом проекте TDD скорее лишний груз, который тянет команду назад. Который заставляет тратить время на то, что потом будет выброшено на помойку а результатом будет только излишнее раздражение команды.
В конце концов, все разработчики делятся на два типа: те кто не любит писать тесты, и те кто пи… врут.
Разработка с TDD, как вы ожидаете это будет: написали тесты, написали код, выкатили, проверили, получили фидбек, утвердили, пошли дальше.
Как это есть на самом деле: написали тесты, написали код, выкатили, проверили, получили фидбек, не утвердили, переписали тесты, доправили код, повторили итерацию сначала ещё 2-4 раза.
Разработка code first: написали, выкатили, проверили, утвердили/не утвердили (и повторили 2 шага итерации), покрыли тестами, двинулись дальше.
Экономим время (но и хрен бы с ним), экономим нервы (а вот это уже ценно).
Не стоит считать что TDD — панацея. Стоит четко понимать, когда TDD стоит применять (четкое, неизменное ТЗ), а когда это просто не выгодно и безсмысленно. В частности в гибком и часто меняемом проекте TDD скорее лишний груз, который тянет команду назад. Который заставляет тратить время на то, что потом будет выброшено на помойку а результатом будет только излишнее раздражение команды.
В конце концов, все разработчики делятся на два типа: те кто не любит писать тесты, и те кто пи… врут.
Как раз таки TDD при меняющихся требованиях и/или переработке архитектуры — очень хорошее подспорье. Где гарантия, что при переписывании части кода другая часть останется рабочей? Вот в тестах она как раз и есть. Не 100%, согласен, но есть.
Конечно, когда разработка представляет из себя последовательность экспериментов (написали, понравилось — оставили, не понравилось — выкинули), TDD будет лишним грузом.
Да нет, тут, скорее, как с бэкапами. Есть те, кто не любит писать тесты, и есть те, кто уже любит.
С какого-то момента я превратился в Спаси_Мой_Проект парня. Приходишь на проект, а там ад. Разработка наполовину состоит из борьбы с другими разработчиками за работоспособность своего участка кода. Проект объемный, перетыкивать каждый его кусок долго и утомительно. Дать гарантии, что при изменении функции что-то не посыпется не может дать никто, а так оно обычно и бывает. И вот в какой-то момент я говорю «хватит, парни, начинаем писать тесты». Если кто-то пушнул что-то в репозиторий, не прогнав предварительно тесты, сразу получает по рукам.
А сейчас я спасаю очередной проект, но «на тесты у нас времени нет». Что я делаю: пишу кусок кода, удаляю старые данные, завожу новые, чистые, провожу ряд действий, проверяю результаты, копаясь в БД и пересчитывая ручками корректность полученных данных. Т.е. делаю все то, что сделали бы тесты, но руками. Скорость проверки работоспособности упала более чем в 100 раз. Но на тесты у нас все еще «нет времени».
Конечно, когда разработка представляет из себя последовательность экспериментов (написали, понравилось — оставили, не понравилось — выкинули), TDD будет лишним грузом.
В конце концов, все разработчики делятся на два типа: те кто не любит писать тесты, и те кто пи… врут.
Да нет, тут, скорее, как с бэкапами. Есть те, кто не любит писать тесты, и есть те, кто уже любит.
С какого-то момента я превратился в Спаси_Мой_Проект парня. Приходишь на проект, а там ад. Разработка наполовину состоит из борьбы с другими разработчиками за работоспособность своего участка кода. Проект объемный, перетыкивать каждый его кусок долго и утомительно. Дать гарантии, что при изменении функции что-то не посыпется не может дать никто, а так оно обычно и бывает. И вот в какой-то момент я говорю «хватит, парни, начинаем писать тесты». Если кто-то пушнул что-то в репозиторий, не прогнав предварительно тесты, сразу получает по рукам.
А сейчас я спасаю очередной проект, но «на тесты у нас времени нет». Что я делаю: пишу кусок кода, удаляю старые данные, завожу новые, чистые, провожу ряд действий, проверяю результаты, копаясь в БД и пересчитывая ручками корректность полученных данных. Т.е. делаю все то, что сделали бы тесты, но руками. Скорость проверки работоспособности упала более чем в 100 раз. Но на тесты у нас все еще «нет времени».
Т.е. делаю все то, что сделали бы тесты, но руками. Скорость проверки работоспособности упала более чем в 100 раз. Но на тесты у нас все еще «нет времени».
А почему вы сами не автоматизировали это? Ответ вам подскажет, почему программисты не написали тесты.
Я уже писал причину: У нас, якобы, нет времени на написание тестов, заказчик не готов оплачивать это время. Зато со временем на прогон этих самых тестов вручную — все ок. Это поразительное желание переплачивать деньги и тратить время, иного объяснения нет.
Но вы бы могли написать тесты, чтобы облегчить себе работу, не сдавая тесты заказчику :)
Мог бы, но мне бы за это не заплатили. Только не говорите мне о высшем благе, и о том, что я должен работать за идею.
Вы бы сделали быстрее свою работу и пошли смотреть котиков на ютюбе. Заказчику всё равно, а вам легче.
Если было бы все равно, я бы даже не спрашивал про тесты, а заказчик бы не интересовался. Но у меня почасовая система оплаты.
В вашем случае и рефакторинг средствами IDE — плохая идея.
Ведь можно больше денег заработать, проводя его вручную.
В общем-то, не вижу никакой разницы между этим примером и написанием тестов «для себя».
В обоих случаях должна повышаться собственная эффективность.
Ведь можно больше денег заработать, проводя его вручную.
В общем-то, не вижу никакой разницы между этим примером и написанием тестов «для себя».
В обоих случаях должна повышаться собственная эффективность.
Это уже уход в сторону и кривая логика с вашей стороны.
Рефакторинг средствами IDE не требует какой-либо подготовки. Тесты же требуют времени для их написания. Быстро выполнив рефакторинг, я ничего не потеряю, т.к. просто приступлю к другой задаче. Написав тесты бесплатно, я потеряю стоимость потраченного на них времени. Улавливаете, о чем я? Я стараюсь делать работу быстро, но я не буду делать ее бесплатно.
Рефакторинг средствами IDE не требует какой-либо подготовки. Тесты же требуют времени для их написания. Быстро выполнив рефакторинг, я ничего не потеряю, т.к. просто приступлю к другой задаче. Написав тесты бесплатно, я потеряю стоимость потраченного на них времени. Улавливаете, о чем я? Я стараюсь делать работу быстро, но я не буду делать ее бесплатно.
Другой пример: нужно написать ORM-обёртки для базы данных.
В базе 1000 таблиц, готового генератора нет.
Вы будете вручную писать 1000 классов или разработаете генератор, за который вам не заплатят, и им быстро сделаете работу?
В базе 1000 таблиц, готового генератора нет.
Вы будете вручную писать 1000 классов или разработаете генератор, за который вам не заплатят, и им быстро сделаете работу?
Это демагогия. В данном случае я просто не возьмусь за работу, если мне не заплатят за генератор.
Впрочем, заказчику тут очевидно, что генератор быстрее. С тестами — не вполне.
Или, всё-таки, тесты — это трата времени, а не ускорение разработки? ;)
>>>апологет… рассказывает о степени позитивного влияния TDD на разработку… и делится экспертизой внедрения и неукоснительного каждодневного применения этой техники
>> — Давайте «сразу определимся». Я не использую TDD в его классическом понимании.
И это всё о ТDD.
>> — Давайте «сразу определимся». Я не использую TDD в его классическом понимании.
И это всё о ТDD.
Половина вопросов в стиле «TDD практикуют только пассивные геи. Что вы на это скажете?»
habrahabr.ru/post/56975/#comment_1530779
CNP — Chuck Norris Process предписывает удалить код предыдущего разработчика, применявшего методологию NoDDD (No Design Driven Development), и переписать все заново.
Есть вещи, которые невозможно протестировать вообще никакими автоматизированными тестами.
Например, реализация современных технологий рендеринга трехмерной графики.
Скажем, реализация Deffered Lightning — отложенного освещения на OpenGL. И как тут писать автоматизированный тест?
У компоненты, производящей рендеринг нету интерфейса, с помощью которого можно узнать «состояние всего».
Как мы проверим автоматизированным тестом, загрузили ли мы текстуры в VBO или биндим их из оперативки? Ведь сама картинка даже не поменяется. Или как проверить используем ли мы массив треугольников с вершинами, массив нормалей и массив текстурных координат Или мы используем массив вершин, массив нормалей, массив текстурных координат и массив треуголников с индексами на предыдущие массивы?
Например, реализация современных технологий рендеринга трехмерной графики.
Скажем, реализация Deffered Lightning — отложенного освещения на OpenGL. И как тут писать автоматизированный тест?
У компоненты, производящей рендеринг нету интерфейса, с помощью которого можно узнать «состояние всего».
Как мы проверим автоматизированным тестом, загрузили ли мы текстуры в VBO или биндим их из оперативки? Ведь сама картинка даже не поменяется. Или как проверить используем ли мы массив треугольников с вершинами, массив нормалей и массив текстурных координат Или мы используем массив вершин, массив нормалей, массив текстурных координат и массив треуголников с индексами на предыдущие массивы?
Интересный вопрос. Хотелось бы услышать ответ, ведь наверняка какие-то решения есть.)
>>>Ведь сама картинка даже не поменяется.
А что поменяется?
А что поменяется?
Поменяется способ рендеринга, производительность, кол-во оперативной и видеопамяти. Т.е. по другому распределятся ресурсы. Возможно ( при других обстоятельствах, не пр работе с VBO, например при настройке точности Z- bufferа и передней и задней плоскости отсечения) могут вылезти графические артефакты.
Вот и вопрос: как проверить что артефактов не будет и будут правильно распределяться ресурсы и т.д.?
Вот и вопрос: как проверить что артефактов не будет и будут правильно распределяться ресурсы и т.д.?
тесты как и требования деляться на функциональные и performance и всякие другие соответственно отдельно проверять корректность, отдельно производительность. И автоиатизировать
ну и как корректность то проверить? Если выходных данных ты не имеешь кроме картинки на экране.
А пиксели нельзя прочитать и сравнить?
Почитайте книжку How Google Tests Software как они браузер тестировали.
Правда вам может не подойти, если вы не гугл.
Почитайте книжку How Google Tests Software как они браузер тестировали.
Правда вам может не подойти, если вы не гугл.
А пиксели нельзя прочитать и сравнить?
Хороший тест должен проверять одну фичу и не ломаться при добавлении других фич.
Сделали «тест» на освещение, а завтра в движок добавили сглаживание или светофильтры и все пиксели изменились.
Если при повседневных изменениях нужно проверять всё вручную и вписывать во все «тесты» новые пиксели, от такого TDD больше хлопот, чем пользы.
Хороший тест должен проверять одну фичу и не ломаться при добавлении других фич.
Хороший юнит тест для акцептанс, и интегрейшен тестов это не так.
Если при повседневных изменениях нужно проверять всё вручную и вписывать во все «тесты» новые пиксели, от такого TDD больше хлопот, чем пользы.
В гугле, как я понял, весь этот геморрой и происходит. Зависит от размера ущерба в случае поломки. Представьте, если например в случае неправильного рендеринга в продакшене у вас отрезают палец. :)
Хороший юнит тест для акцептанс, и интегрейшен тестов это не так.
Если при повседневных изменениях нужно проверять всё вручную и вписывать во все «тесты» новые пиксели, от такого TDD больше хлопот, чем пользы.
В гугле, как я понял, весь этот геморрой и происходит. Зависит от размера ущерба в случае поломки. Представьте, если например в случае неправильного рендеринга в продакшене у вас отрезают палец. :)
Что мешает тестировать освещение без сглаживания и светофильтров?
1) Возможно, в следующей версии рендера эти фичи стали «бесплатными» (например, какие-то коэффициенты в шейдерах) и чтобы их отключить, чтобы получить попиксельное совпадение со старой версией кода, нужно иметь отдельную версию движка
2) Будет тестироваться такой набор настроек, который в реальном приложении никогда не будет применяться. Есть шанс, что от включения свегофильтров начнёт глючить освещение, и тест на освещение с выключенными светофильтрами ничего не поймает.
В любом случае, тест придётся дописывать, чтобы переконфигурировать движок, отключив новые фичи. Раз уж возвращаемся к тесту, надёжнее обновить эталонные пиксели, проверив корректность освещения вручную.
2) Будет тестироваться такой набор настроек, который в реальном приложении никогда не будет применяться. Есть шанс, что от включения свегофильтров начнёт глючить освещение, и тест на освещение с выключенными светофильтрами ничего не поймает.
В любом случае, тест придётся дописывать, чтобы переконфигурировать движок, отключив новые фичи. Раз уж возвращаемся к тесту, надёжнее обновить эталонные пиксели, проверив корректность освещения вручную.
вот-вот и я про то-же.
И вообще попиксельный тест хорошо ляжет, если мы например производим портирование движка на другую версию графического пайплайна, например переходим с DirectX на OpenGL или со старого OpenGL на OpenGL с новым пайплайном. А иначе нам и эти точки брать неоткуда, как мы их будем генерить если ничего нету изначально, сами вручную 2 млн. точек в графическом редакторе рисовать чтоли?
Вобщем геммора с этими тестами на рендеринг много, кроме одного полезного нюанса:
Можно проверять правильность рендеринга при переходе на другой GAPI или на другой пайплайн.
Нашел книгу.
Прочитал тот момент когда чувак сравнивал пиксели, всмысле пытался распознать HTML элементы по пикселям ( цвет RGB неважен). Ну так тестовая компонента должна хорошо распознавать образы, если она будет криво распознавать, то тест будет провален.
К тому же чуваки сравнивали получившуюся картинку с уже имеющейся (от предыдущих версий браузеров или браузеров других производителей)
А вот если такой картинки нет? 2 млн пикселей раскрашивать вручную в граф редакторе как то не улыбается.
К тому же тест только отловит сам факт бага, без указания на причину.
Есть конечно альтернативная идея:
написать своё GAPI-заглушку, но вот что поместить внутри не совсем понятно. Искусственный интеллект? Жесткую проверку?
Такой тест будет только проверять наличие того, сего, пятого, десятого и порядок вызова их. Может быть сможет отлавливать какие то известные графические артефакты-баги.
Но идея с чтением пикселей полезна:
Например, можно сравнивать рендеринг старой и новой версии движка при тех же исходных данных. Ну скажем, захотели мы портировать нашу игруху скажем на планшет.)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Test-Driven Development — телега или лошадь?