20 декабря 2013 в 18:27

Test-Driven Development — телега или лошадь?

Test Driven Development (TDD) – неоспоримо выдающаяся техника, дающая ряд преимуществ. Прикладные разработчики, причём вне зависимости от масштаба проекта и количества вовлеченных специалистов, в широкой массе не следуют TDD. Но есть и ярые сторонники такого подхода, причём они готовы апеллировать не только к здравому смыслу или производственной необходимости, но и на безоговорочно успешные примеры его внедрения. Одним из таких апологетов является Александр Люлин, который не только рассказывает о степени позитивного влияния TDD на разработку, но и делится экспертизой внедрения и неукоснительного каждодневного применения этой техники вплоть до исходных кодов и примеров сценариев (в своем блоге). Однако главный тормоз на пути следования принципам TDD стоит, что предсказуемо, набор чисто психологических установок. В режиме «жёсткого разговора» мы пообщаемся с Александром на тему необходимости Test Driven Development.

Test Driven Development – попытка следования моде? Слепое копирование чужих подходов?

Давайте «сразу определимся». Я не использую TDD в его классическом понимании. И не надо здесь цитировать «википедию»! Вообще, вряд ли кто-то из профессионалов рассматривает энциклопедические статьи в качестве руководства к действию. Мы свой подход «выстрадали» в рамках реализации успешного проекта, поэтому за нами реальный опыт, а не «тупое использование чужих идей». Скорее, мы используем синтез из TDD и собственных представлений о том, как нужно разрабатывать ПО. Даже если эти «внешние идеи» исходят от очень умных людей, их следует критически осмыслить и адаптировать к реальной компании, существующей команды и стратегии развития и обеспечения качества. Но я далее буду говорить «TDD», имея ввиду тот процесс “разработки через тестирования», который близко соотносится с энциклопедическим Test Driven Development, но идёт гораздо дальше него.

TDD — это попытка поставить всё с ног на голову. В классике инженерного дела сначала создаётся установка/техническая система/машина/агрегат. Конечно, методика испытаний имеется в виду при проектировании… но всё-так, программисты – это какой-то особый вид инженеров? Генетически ущербных? Сами себя таким не считаете?




Тут всё зависит от определения — что «голова», а что «ноги». И как известно самый научный спор — это спор о терминах. Если говорить о методики испытаний как самодостаточной и глубоко проработанной дисциплине, то нельзя сказать, что она есть в промышленных масштабах. Тогда бы она де-факто присутствовала везде и никакой полемики не было бы в принципе. Но это, собственно, не отличает нас принципиально от других инженеров, которые, например, делают кофеварки, газонокосилки или велосипеды (не путать с «велосипедами»).

image

Считаю ли я себя «генетически ущербным»? В силу профессии, отчасти, да. Поэтому и стремлюсь всеми силами стать лучше. Разработка ПО – инженерное ремесло, поэтому не надо вдруг себя считать суперменом или неким творцом. Мы – ремесленники (за исключением единиц), это нужно осознать и смириться. И попытаться стать нормальным (а не генетически ущербным) инженером – допуски, чертежи, методики испытаний и т.д.

TDD — сковывает инициативу разработчика. Уже не сам разработчик контролирует процесс, а задание «валится на него снеговыми комками»? Нет ли психологического дискомфорта? Программист у нас теперь не творец, а бездумная машина реализации им функционала?

Наоборот, TDD ничего не сковывает, но позволяет работать более продуктивно. Конечно, «продуктивно» означает «больше работать». Вместо одного класса приходится писать два: сам проектируемый класс и тест к нему. TDD это как раз для инициативных людей. Которые любят свою работу. Если есть желание оптимизировать (=сэкономить своё рабочее время), то это уже в дверь с надписью «для бездельников». Потенциальные бездельники или люди, практикующие безделье в рабочее время, могут дальше не читать.

image

Только никто не контролирует разработчика, он сам себя контролирует – «бьёт по рукам». Но это не мазохизм. Взамен разработчик получает кое-что важное – ощущение стабильности и уверенности в своём профессиональном завтрашнем дне. А как творец – он творит в два раза больше. Именно творит, а не «пашет». Пашет он как раз меньше. Жду следующего вопроса для разъяснений.

TDD — ставит во главу угла не качество реализации, а сиюминутные фичи. Как можно говорить о качестве кода? Об архитектуре системы? Мы на выходе с точки зрения программного кода получаем «салат оливье» — механическую смесь разных на вкус и цвет мелкопорезанных кусочков? Вы верите, что из винегрета, сложенный большой кучкой может символизировать собой архитектурное совершенно и конструктивное качество?

Вот это – совсем уж неправда. Именно качество и стабильность ставится во главу угла. Как раз, есть «фича» – есть тест, подтверждающий, что это «фича», а не «бага». Что не попало в ТЗ, то не попало в тесты, откуда тогда оно возьмётся в функционале? Только так: желание заказчика выражается в ТЗ, оттуда перетекает в тесты, и только потом появляется функционал.

image

Теперь про архитектуру… Архитектура это не есть что-то универсальное и самоценное. И не есть серебряная пуля. И не то, из чего делается плохая пуля. Я знаю архитектуру системы, т.к. я 15 лет ей занимаюсь и знаю великолепно, спасибо UML-чертежам. У меня полный набор проектных решений в виде UML-диаграмм. Но и здесь есть вероятность не удержать всё в памяти. Как всё это восстановить в памяти? Просто на конкретный тест посмотреть.
Тесты — это «архивированная память», а также «документация» и «варианты использования».

При этом тесты — более стабильны и инвариантны по сравнению с проектным кодом. Код перерождается. Эволюционирует. Умирает. С тестами это происходит гораздо реже. Видите, нет никакого конфликта интересов у архитектуры и тестов. И они в своей связке важнее кода.

image

TDD – некий бич, которым хлещут непокорных IT-рабов? Это что – некий вид «управы» на свободолюбцев, гордо именуемых «разработчиками»? Вы, разрабочтики, не должны думать. Ваша дело – тянуть лямку, выполнять план по валу! Смотри на тесты, данные тобой свыше, и не вздумай проявлять инициативу!

Значит так… «Руководству», (директорату и тем более заказчикам) реально нет дела, какие технологии используются (за редкими исключениями, на что мы надеяться не будем). Вообще, никого не парит, и что там «внутри» делают разработчики. Используют они RUP, TDD/ШмеДД, Agile/СуперАгиле или что-то иное…

image

Всем выше перечисленным «стейкхолдерам» – важен результат, а не процесс. Никакой здравомыслящий начальник не будет навязывать TDD. Ему нужен результат, а не раздражение разработчиков — «вот этот умник опять какие-то новомодные фишки нам навязывает». Умный начальник… реально умный (в IT это чаще, чем в других областях) может лишь сделать так, чтобы разработчики сами почувствовали эту необходимость. Это – единственный путь, иначе – тупик.

Нету никаких тестов, данных свыше. Тесты это — внутреннее дело разработчиков. И чем лучше тесты и чем их больше, тем разработчики «крепче спят». И тем меньше они вызываются на ковёр. Тесты – для разработчиков, не для начальников.

TDD – попытка некомпетентных и далёких от кодирования людей продвигать свою, чуждую разработчикам идеологию… своё, часто неправильное видение стратегии развития продукта.

Ещё раз. Тесты не диктует «директорат», руководство или заказчики. Тесты — это средство разработки. Тесты это – «внутренняя кухня» разработчиков и группы качества. Все остальные «стейкхолдеры» оперируют ТЗ. Ну или «экранами». Максимум… Тесты и «стратегия развития» вообще никак не соотносятся.

Допустим, меня обязали следовать технике TDD, хотя, согласитесь, очень многие люди комфортно чувствуют себя без этого. Ну и что это даёт по сравнению с нормальной техникой, когда «запланировали – реализовали – сделали тесты – протестировали»? Просто «красивая сказка» для начальника «мы используем передовые подходы?»

Можно же быть таким упёртым противником TDD! «Обязать» использовать тесты невозможно. Можно лишь уговорить. Если кто-то чувствует себя комфортно без тестов, то значит, что:
— его проект не такой сложный;
— он всё тестирует на реальных пользователях (не повезло им)
— он гений;
— он работает один.
Давайте, посмотрим в зеркало и выберем свою категорию.

image

Ещё раз: «Сказки» — нет, начальству – всё равно, ему нужен результат, сроки и качество.

Напахал я тестов. Начал под них (скрепя сердце) подгонять функциональный код. Выясняется… потом, что тест придуман неправильно. Я поработал впустую?

Вот «напахивать» ничего не надо. Одна фича – один тест. Итеративно. Фича порождает тест, а тест порождает фичу. XP, kiss-принцип.

А не бывает такого, что «тесты», которые приобрели вид «жёсткого задания», начали противоречить друг-другу?

Это мой любимый вопрос из разряда «гениальных»! Если тесты противоречат друг-другу, значит:
— ТЗ недостаточно проработано;
— ТЗ противоречиво.
Тут надо сказать «спасибо» тестам и вернутся к проработке ТЗ.

TDD – потеря времени. Давайте уж сначала напишем код, а потом будем его тестировать. Любое хождение «задом-наперёд», ненатуральный порядок разработки, даже если не сказывается на качестве, обязательно вызовет «тормоза».

Логично. Так многие и делают. Напишем код. Напишем. Покоммитим его в CVS/SVN. И что? Мы свою работу сделали? Типа «как повезёт»? Прокатит/не прокатит? Можно и так. Только потом тебя «поднимут с постели» и спросят «что за хрень ты тут написал?» Так?

Можно ведь по-другому — написать код и проверить его. А как мы его будем проверять? «Тупым» протыкиванием?
А если для «протыкивания» надо сделать 20-ть шагов? А если 100? А если «данных нет»? А если «смежники не готовы»? Не проще ли «написать тест» хотя бы для отладки? С придуманными «из головы» входом и выходом. По-моему, проще. А если тест УЖЕ написан и использовался для отладки, то почему не включить этот тест в «ночную сборку»?

image

TDD – способ поставить разработчика в унизительное положение. «Битый небитого везёт». Программист работает «от чувства вины» в перманентном состоянии нереализованности поставленной задачи.

Наоборот, у программиста есть всегда «реперные точки». Тут вот я написал тест. Он не проходит. Тут я реализовал функционал. Тест стал проходить.
Я всё покоммитил в CVS/SVN. Я свою работу СДЕЛАЛ и «могу спать спокойно».

TDD – нет ли ощущения, что программист всё время решает обратную задачу? Или разработчик – двоечник, подгоняющий решение под ответ задачи?

А программисты всегда решают обратную задачу. Ну или «строят сферического коня в вакууме». Программист – не двоечник, а обычный человек, который не может предусмотреть всё. Но зато то, что он предусмотрел – гарантировано работает. Есть и другие люди. Но они – гении, но их мало.

TDD – разработка в зазеркалье. Мы выполнили тесты, что не есть гарантия безошибочности. Кто отвечает за качество тестов?

Гарантии полной безошибочности" нет. Есть лишь гарантия того, что разработчик правильно понял ТЗ и реализовал его так, как понял.

TDD – телега впереди лошади. Лошадь постоянно тыкается мордой «в задний бампер», не видя ничего впереди себя. Как можно говорить о продумывании функционала в целом на уровне архитектуры системы, когда впереди – вдаль до самого горизонта – просто свалка потребностей?

Вот тут опять давайте вернёмся к «самому научному спору». Определим термины, что – телега, а что – лошадь. И не надо мне грозить википедией (как можно тестировать то, чего нет)?

Вот так будет правильно:
— «лошадь» — это ТЗ;
— «телега» — это КОД.

А что есть тесты? Тесты это — «оглобли» которыми лошадь привязана к телеге. Везёт весь процесс ТЗ, а тесты тянут за собой код и проверяют его соответствие ТЗ. Код едет в ту сторону, что и ТЗ. Нету ни TestFirst! Ни CodeFirst! Есть ТЗ-first. Но это если упрощённо. Цепочка выглядит так: ТЗ -> Набросок архитектуры -> Тест -> Код, а дальше возможны варианты.

ТЗ -> Набросок архитектуры -> Тест -> Код -> Тест -> Код
ТЗ -> Набросок архитектуры -> Тест -> Код -> Архитектура -> Тест -> Код
ТЗ -> Набросок архитектуры -> Тест -> Код -> Архитектура -> Тест -> Код -> ТЗ -> Архитектура -> Тест -> Код
…и т.д. и т.п.

First: ТЗ и набросок архитектуры, дальше начинается итерационная разработка.
И что особенно вкусно, что как только мы написали тест, нам не надо думать, а где проверять работоспособность нашего класса? Мы уже настроили всю инфраструктуру для его тестирования и проверки. Именно это и означает слово Driven в TDD.

image

Ладно, есть на свете «извращенцы». Тогда хоть как можно облегчить страдания? Какой правильный процесс при этом?

Не, ну спасибо за эпитет. Цепочку я описал выше. Если мозг готов, то процесс выстроится сам собой. Дальше то вопрос в выборе инструментария.

Ладно, мы теперь не извращенцы, а правильные разработчики. Как впрячь коня (упрямого тестового пони на коротких ножках) и трепетную лань (мысль разработчика)?

Значит про «мысль». С разработчиком нужно тусоваться, поить пивом (шучу). Уговаривать. Развлекать. Сделать так, чтобы он тебе поверил. И чтобы считал твои мысли своими (привет Карнеги). По-другому — никак. Заставить – нельзя. Как и нельзя заставить писать хороший код. Можно подарить человеку книгу Мак-Конела на день Рождения. Но не более того. Никакие административные меры не помогут, а вызовут лишь озлобление.

Инструментарий, который мы используем:
— DUnit.
Доработки к DUnit;
Confluence;
— самописный аналог JIRA; в ту пору JIRA была ещё «сыра» поэтому мы её не взяли; сейчас — я думаю — взяли бы её;
скриптовая машина;
— FishEye (https://www.atlassian.com/software/fisheye/overview);
— Доработки к Confluence и FishEye позволяющие отслеживать связь коммитов, изменений кода и строящие привязку конкретных изменений кода к конкретным задачам;
— интеграция UML и Confluence;

image

Кто создает тесты? А если «роль» создателя тестов не предполагает знание программирования?

Тесты создают разработчики. Если речь идёт о новой функциональности.
Или тестировщики. Если речь идёт об ошибках.
И чаще всего, тестировщики пишут ошибку и сразу пишут к ней тест.
Тут кстати надо понимать одну простую вещь, ТЗ и ошибки в общем-то ничем не отличаются друг от друга принципиально. Только лишь «зоной ответственности».
«А если «роль» создателя тестов не предполагает знание программирования?» — на BDD или Fit-таблицы — мы пока не «замахивались», но мы работаем над этим.

TDD – это наше «всё» или Вы всё-таки признаёте ограниченность данной техники?

«Разруха она в головах, а не в коде». Нет ограниченности. Есть нежелание применять.

Ко всем ли системам применима техника TDD? Есть «особые случаи» или «другие подходы»?

Нет «особых случаев». Есть желание разработчиков «спать спокойно» и не думать лишнего, сохраняя нервы.

image

Есть что-то что можно выкинуть из TDD, есть что-то что можно привнести. Но в целом, TDD остаётся и гарантирует отсутствие паники. Panic-Driven Development исключается.

Что привело Вас к TDD?

Нужда. По мере роста сложности системы мы поняли, что «делаем одно», «отваливается другое». Тогда тесты стали необходимой составляющей. Мы к ним пришли эволюционно, но все к этому рано или поздно приходят. Также эволюционно перешли и к TDD. Внезапно оказалось. Что тесты не только полезно, но и удобно. Не надо инфраструктуру настраивать каждый раз. Написали тест, окружение для отладки готово, запускай этот тест хоть миллион раз. Так что кто уже «почувствовал» — welcome to TDD.

Что по-Вашему может быть лучше, чем TDD?

BDD. Есть люди в мире Delphi, которые этим занимаются и пропагандируют. Роман Янковский над этим работает. Ну и Fit-таблицы. Если есть желание развиваться, то можно до много самому дойти. Либо воспользоваться полунамёками, отрывочными статьями, википедией (в крайнем случае). Но сегодня я рассказал о реально работающем процессе. В деталях пишу в своём блоге, но общение с аудиторией доказало (выходя за рамки читателей), что главная проблема именно в понимании ценности TDD. Об этом сегодня попытался рассказать.

Ничего, что часть вопросов прозвучала как «троллинг»?

В жизни и не такое случалось, когда внедряли TDD в производственный процесс. Нормальная реакция.

image
Ваше отношение к TDD

Проголосовало 416 человек. Воздержалось 195 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

@VsevolodLeonov
карма
0,0
рейтинг 0,0
Похожие публикации
Самое читаемое Разработка

Комментарии (34)

  • +2
    TDD хорошо когда есть четкое ТЗ и понимание что структура завтра не поменяется из-за изменившихся требований. Когда разработчик знает что «вот я щас напишу тесты, напишу код, всё заработает, и мне не надо будет это всё переделывать потом». К сожалению, реалии зачастую таковы, что клиент по ходу дела хочет то, хочет это, а потом так, сяк, и ещё эдак. И его не останавливает уже ПМовское «изменения > время > деньги». У него есть деньги, он хочет капризы. И когда 30-50% проекта переписывается, 15-25% codebase выбрасывается, а какой-то участок меняется уже четвертый раз, задумываешься — а стоит ли каждый раз писать тесты?.. В итоге примерно 15-20% времени разработчика улетает в пустоту. Коту под хвост. И опять, опять писать эти чёртовы тесты на эти чёртовы изменившиеся требования.

    Разработка с TDD, как вы ожидаете это будет: написали тесты, написали код, выкатили, проверили, получили фидбек, утвердили, пошли дальше.
    Как это есть на самом деле: написали тесты, написали код, выкатили, проверили, получили фидбек, не утвердили, переписали тесты, доправили код, повторили итерацию сначала ещё 2-4 раза.
    Разработка code first: написали, выкатили, проверили, утвердили/не утвердили (и повторили 2 шага итерации), покрыли тестами, двинулись дальше.
    Экономим время (но и хрен бы с ним), экономим нервы (а вот это уже ценно).

    Не стоит считать что TDD — панацея. Стоит четко понимать, когда TDD стоит применять (четкое, неизменное ТЗ), а когда это просто не выгодно и безсмысленно. В частности в гибком и часто меняемом проекте TDD скорее лишний груз, который тянет команду назад. Который заставляет тратить время на то, что потом будет выброшено на помойку а результатом будет только излишнее раздражение команды.
    В конце концов, все разработчики делятся на два типа: те кто не любит писать тесты, и те кто пи… врут.
    • +3
      Как раз таки TDD при меняющихся требованиях и/или переработке архитектуры — очень хорошее подспорье. Где гарантия, что при переписывании части кода другая часть останется рабочей? Вот в тестах она как раз и есть. Не 100%, согласен, но есть.
      Конечно, когда разработка представляет из себя последовательность экспериментов (написали, понравилось — оставили, не понравилось — выкинули), TDD будет лишним грузом.

      В конце концов, все разработчики делятся на два типа: те кто не любит писать тесты, и те кто пи… врут.

      Да нет, тут, скорее, как с бэкапами. Есть те, кто не любит писать тесты, и есть те, кто уже любит.

      С какого-то момента я превратился в Спаси_Мой_Проект парня. Приходишь на проект, а там ад. Разработка наполовину состоит из борьбы с другими разработчиками за работоспособность своего участка кода. Проект объемный, перетыкивать каждый его кусок долго и утомительно. Дать гарантии, что при изменении функции что-то не посыпется не может дать никто, а так оно обычно и бывает. И вот в какой-то момент я говорю «хватит, парни, начинаем писать тесты». Если кто-то пушнул что-то в репозиторий, не прогнав предварительно тесты, сразу получает по рукам.
      А сейчас я спасаю очередной проект, но «на тесты у нас времени нет». Что я делаю: пишу кусок кода, удаляю старые данные, завожу новые, чистые, провожу ряд действий, проверяю результаты, копаясь в БД и пересчитывая ручками корректность полученных данных. Т.е. делаю все то, что сделали бы тесты, но руками. Скорость проверки работоспособности упала более чем в 100 раз. Но на тесты у нас все еще «нет времени».
      • 0
        Т.е. делаю все то, что сделали бы тесты, но руками. Скорость проверки работоспособности упала более чем в 100 раз. Но на тесты у нас все еще «нет времени».

        А почему вы сами не автоматизировали это? Ответ вам подскажет, почему программисты не написали тесты.
        • 0
          Я уже писал причину: У нас, якобы, нет времени на написание тестов, заказчик не готов оплачивать это время. Зато со временем на прогон этих самых тестов вручную — все ок. Это поразительное желание переплачивать деньги и тратить время, иного объяснения нет.
          • 0
            Но вы бы могли написать тесты, чтобы облегчить себе работу, не сдавая тесты заказчику :)
            • 0
              Мог бы, но мне бы за это не заплатили. Только не говорите мне о высшем благе, и о том, что я должен работать за идею.
              • 0
                Вы бы сделали быстрее свою работу и пошли смотреть котиков на ютюбе. Заказчику всё равно, а вам легче.
                • 0
                  Если было бы все равно, я бы даже не спрашивал про тесты, а заказчик бы не интересовался. Но у меня почасовая система оплаты.
                  • 0
                    В вашем случае и рефакторинг средствами IDE — плохая идея.

                    Ведь можно больше денег заработать, проводя его вручную.
                    В общем-то, не вижу никакой разницы между этим примером и написанием тестов «для себя».
                    В обоих случаях должна повышаться собственная эффективность.
                    • 0
                      Это уже уход в сторону и кривая логика с вашей стороны.

                      Рефакторинг средствами IDE не требует какой-либо подготовки. Тесты же требуют времени для их написания. Быстро выполнив рефакторинг, я ничего не потеряю, т.к. просто приступлю к другой задаче. Написав тесты бесплатно, я потеряю стоимость потраченного на них времени. Улавливаете, о чем я? Я стараюсь делать работу быстро, но я не буду делать ее бесплатно.
                      • 0
                        Другой пример: нужно написать ORM-обёртки для базы данных.
                        В базе 1000 таблиц, готового генератора нет.

                        Вы будете вручную писать 1000 классов или разработаете генератор, за который вам не заплатят, и им быстро сделаете работу?
                        • 0
                          Это демагогия. В данном случае я просто не возьмусь за работу, если мне не заплатят за генератор.
                          • 0
                            А так ли заказчику интересна ваша внутренняя кухня?
                            Так и представляю: «если тут использовать паттерн 'адаптер', это вам будет стоить дополнительно 500 руб., но потом легче будет поддерживать и следующую часть я напишу на 1200 руб. дешевле».
                            • 0
                              Я выше уже писал: если бы заказчику не было интересно, его бы никто не спрашивал.
                              • 0
                                Понятно. Видимо, у вас не только почасовая оплата, но и почасовая отчётность.
                                Поэтому «писал 2 часа тесты» вызовет реакцию «а нахрена», а «тестировал 6 часов вручную» — «молодец».
                        • 0
                          Впрочем, заказчику тут очевидно, что генератор быстрее. С тестами — не вполне.
                  • 0
                    Или, всё-таки, тесты — это трата времени, а не ускорение разработки? ;)
                    • 0
                      Это зависит от того, насколько фикс получившихся багов входит в стоимость разработки. Насколько я помню сравнительные исследования на при tdd уходит на 30% больше времени, но в результате получается в 10раз меньше плотность багов. Еще есть некий эффект от улучшения дизайна.
  • 0
    >>>апологет… рассказывает о степени позитивного влияния TDD на разработку… и делится экспертизой внедрения и неукоснительного каждодневного применения этой техники
    >> — Давайте «сразу определимся». Я не использую TDD в его классическом понимании.

    И это всё о ТDD.
  • +2
    Половина вопросов в стиле «TDD практикуют только пассивные геи. Что вы на это скажете?»
  • 0
    habrahabr.ru/post/56975/#comment_1530779
    CNP — Chuck Norris Process предписывает удалить код предыдущего разработчика, применявшего методологию NoDDD (No Design Driven Development), и переписать все заново.
  • +1
    Есть вещи, которые невозможно протестировать вообще никакими автоматизированными тестами.
    Например, реализация современных технологий рендеринга трехмерной графики.

    Скажем, реализация Deffered Lightning — отложенного освещения на OpenGL. И как тут писать автоматизированный тест?
    У компоненты, производящей рендеринг нету интерфейса, с помощью которого можно узнать «состояние всего».
    Как мы проверим автоматизированным тестом, загрузили ли мы текстуры в VBO или биндим их из оперативки? Ведь сама картинка даже не поменяется. Или как проверить используем ли мы массив треугольников с вершинами, массив нормалей и массив текстурных координат Или мы используем массив вершин, массив нормалей, массив текстурных координат и массив треуголников с индексами на предыдущие массивы?
    • 0
      Интересный вопрос. Хотелось бы услышать ответ, ведь наверняка какие-то решения есть.)
    • 0
      >>>Ведь сама картинка даже не поменяется.

      А что поменяется?
      • 0
        Поменяется способ рендеринга, производительность, кол-во оперативной и видеопамяти. Т.е. по другому распределятся ресурсы. Возможно ( при других обстоятельствах, не пр работе с VBO, например при настройке точности Z- bufferа и передней и задней плоскости отсечения) могут вылезти графические артефакты.

        Вот и вопрос: как проверить что артефактов не будет и будут правильно распределяться ресурсы и т.д.?
        • 0
          тесты как и требования деляться на функциональные и performance и всякие другие соответственно отдельно проверять корректность, отдельно производительность. И автоиатизировать
          • 0
            ну и как корректность то проверить? Если выходных данных ты не имеешь кроме картинки на экране.
            • 0
              А пиксели нельзя прочитать и сравнить?
              Почитайте книжку How Google Tests Software как они браузер тестировали.

              Правда вам может не подойти, если вы не гугл.
              • 0
                А пиксели нельзя прочитать и сравнить?

                Хороший тест должен проверять одну фичу и не ломаться при добавлении других фич.
                Сделали «тест» на освещение, а завтра в движок добавили сглаживание или светофильтры и все пиксели изменились.

                Если при повседневных изменениях нужно проверять всё вручную и вписывать во все «тесты» новые пиксели, от такого TDD больше хлопот, чем пользы.
                • 0
                  Хороший тест должен проверять одну фичу и не ломаться при добавлении других фич.

                  Хороший юнит тест для акцептанс, и интегрейшен тестов это не так.

                  Если при повседневных изменениях нужно проверять всё вручную и вписывать во все «тесты» новые пиксели, от такого TDD больше хлопот, чем пользы.

                  В гугле, как я понял, весь этот геморрой и происходит. Зависит от размера ущерба в случае поломки. Представьте, если например в случае неправильного рендеринга в продакшене у вас отрезают палец. :)
                • 0
                  Что мешает тестировать освещение без сглаживания и светофильтров?
                  • 0
                    1) Возможно, в следующей версии рендера эти фичи стали «бесплатными» (например, какие-то коэффициенты в шейдерах) и чтобы их отключить, чтобы получить попиксельное совпадение со старой версией кода, нужно иметь отдельную версию движка
                    2) Будет тестироваться такой набор настроек, который в реальном приложении никогда не будет применяться. Есть шанс, что от включения свегофильтров начнёт глючить освещение, и тест на освещение с выключенными светофильтрами ничего не поймает.

                    В любом случае, тест придётся дописывать, чтобы переконфигурировать движок, отключив новые фичи. Раз уж возвращаемся к тесту, надёжнее обновить эталонные пиксели, проверив корректность освещения вручную.
                    • 0
                      вот-вот и я про то-же. И вообще попиксельный тест хорошо ляжет, если мы например производим портирование движка на другую версию графического пайплайна, например переходим с DirectX на OpenGL или со старого OpenGL на OpenGL с новым пайплайном. А иначе нам и эти точки брать неоткуда, как мы их будем генерить если ничего нету изначально, сами вручную 2 млн. точек в графическом редакторе рисовать чтоли? Вобщем геммора с этими тестами на рендеринг много, кроме одного полезного нюанса: Можно проверять правильность рендеринга при переходе на другой GAPI или на другой пайплайн.
              • 0
                Нашел книгу. Прочитал тот момент когда чувак сравнивал пиксели, всмысле пытался распознать HTML элементы по пикселям ( цвет RGB неважен). Ну так тестовая компонента должна хорошо распознавать образы, если она будет криво распознавать, то тест будет провален. К тому же чуваки сравнивали получившуюся картинку с уже имеющейся (от предыдущих версий браузеров или браузеров других производителей) А вот если такой картинки нет? 2 млн пикселей раскрашивать вручную в граф редакторе как то не улыбается. К тому же тест только отловит сам факт бага, без указания на причину. Есть конечно альтернативная идея: написать своё GAPI-заглушку, но вот что поместить внутри не совсем понятно. Искусственный интеллект? Жесткую проверку? Такой тест будет только проверять наличие того, сего, пятого, десятого и порядок вызова их. Может быть сможет отлавливать какие то известные графические артефакты-баги. Но идея с чтением пикселей полезна: Например, можно сравнивать рендеринг старой и новой версии движка при тех же исходных данных. Ну скажем, захотели мы портировать нашу игруху скажем на планшет.)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.