Войти
ФлеймФорумПрограммирование

Почему хабр торчит от TDD? (4 стр)

Страницы: 13 4 5 640 Следующая »
#45
21:20, 2 фев. 2013

Kartonagnick
> кнопка, тебя нажали
> кнопка ты в нужном состоянии?
Ну это де тривиальная фигня. Зачем тут тест?
В результате нажатия кнопки получается вот такая картинка. Единственный способ проверить корректность работы кода кнопки - проанализировать картинку.

+ Показать

Возможные косяки - это всякие Z-fighting, кривой куллинг, который отрезал блок ландшафта, хотя тот должен был отобразиться, косяк с сортировкой по Z, в результате которого стекло потеряло частично прозрачность.
И прочие вещи. Вероятно их можно отследить программно, но код будет больше и сложнее, чем тот, который картинку выводит.
При этом обезьянка работающая за еду, все косяки почти сразу увидит. Не присматриваясь.

Kartonagnick
> Ваш рендер нельзя проверить программно?  Только глазками?
> Потому что если второе- это плохо.
Отдельные куски можно протестить, но смысла минимум. Потому что если я написал кусок, который, скажем обрезает невидимые блоки - я к нему и не вернусь уже никогда.
У меня был косяк с куллингом и мы не слабо там мозг попарили с тестерами. В итоге сделали тест. Но не автоматический, а опять же визуальный.
Буквально ставилась камера в центр сцены и крутилась. И при повороте было видно, если обрезка не правильно работает.

Писать полностью автоматический тест мне не видится возможным. тест "визуальный" писался за 15 минут и пару минут требовал от тестера для выявления косяков.

#46
21:24, 2 фев. 2013

_zerg_
>Проверяй не содержимое шадоу мапы, а последовательность действий по ее генерации: был ли установлен ли рендер таргет, задана матрица проекции, >установлены ли шейдеры шадоумаппинга, был ли вызов scene->Draw и т.п.
ну это даже как-то не смешно, то есть предлагаешь после того как в коде написана строка SetRenderTarget, написать еще одну в тесте TestRenderTarget которая проверит что она не нулевая, и тоже самое с установкой шейдеров и констант? Может быть еще на каждую строчку сложение двух переменных тест надо сделать? При этом до момента написания кода? TDD такой TDD

innuendo
> TDD придумали для запудривания мозгов ? :)
а хабр, создали как прикрытие )

Kartonagnick
смотри, есть условно говоря "алгоритм" которые состоит из взаимодействия десятка классов и тысяч строк кода, и "дешево" автоматически протестировать ты можешь только результат его работы, а на промежуточных стадиях - крайне трудно. ты вообще веришь что такие случаи могут существовать или это все от "плохого дизайна архитектуры"? Теперь идем дальше, есть "алгоритмы" даже результат работы которых ты "дешево" автоматически протестировать не сможешь, легче посадить девочку с мышкой. То есть даже обычные функциональные автоматические тесты не всегда применимы, а ты говоришь - про универсальный TDD, когда интерфейсы придумываются с первого раза в голове и пишется код для их тестов.

#47
21:28, 2 фев. 2013

@!!ex
> В результате нажатия кнопки получается вот такая картинка. Единственный способ
> проверить корректность работы кода кнопки - проанализировать картинку.

Кнопка отвечает только за собственное состояние. Она ничего не знает о том, что будет, если её кликнули
Проверить работоспособность кнопки - кликать, и ховрить её в разных состояниях.

Это никак не касается никаких картинок.
Кто то отреагировал на кнопку - с него и спрашивайте.

Правильно он отреагировал, или нет. У этой сущности есть собственная идея, регламентируемая тестами

#48
21:30, 2 фев. 2013

thevlad
> мотри, есть условно говоря "алгоритм" которые состоит из взаимодействия десятка
> классов и тысяч строк кода, и "дешево" автоматически протестировать ты можешь
> только результат его работы, а на промежуточных стадиях - крайне трудно. ты
> вообще веришь что такие случаи могут существовать или это все от "плохого
> дизайна архитектуры"?

такие вещи если и существуют, то это явно - хреновый дизайн. Ущербный код.

#49
21:34, 2 фев. 2013

Kartonagnick
>такие вещи если и существуют, то это явно - хреновый дизайн. Ущербный код.
Отлично, сойдемся на том что реальный мир, к сожалению, не совершенен и в чем-то даже ущербен.

#50
21:36, 2 фев. 2013

thevlad
> Отлично, сойдемся на том что реальный мир, к сожалению, не совершенен и в
> чем-то даже ущербен.


Ага, и тесты позволяют ускорить и обезопасить разработку, если поциэнт думает об использовании, а не о реализации. Экономит время.

#51
21:36, 2 фев. 2013

:D TDD это такой повод сказать другому человеку "хреновый дизайн", "ущербный код", "кривая архитектура", "ты мыслишь наизнанку". Почти как ре[не политика]


thevlad
> Может быть еще на каждую строчку сложение двух переменных тест надо сделать?
> При этом до момента написания кода? TDD такой TDD

Ага, а ещё на разных версиях драйверов и разных видеокартах прогонять такой "тест". Все таргеты установлены, все константы переданы, но на экране говно. Вывод ? "Это не из-за бага в GL драйверах AMD, это просто у вас программисты рендера мыслят наизнанку" :D TDD такой TDD

#52
21:48, 2 фев. 2013

ASD
> Ага, а ещё на разных версиях драйверов и разных видеокартах прогонять такой
> "тест". Все таргеты установлены, все константы переданы, но на экране говно.
да, да, каждая строчка складывает как надо, устанавливает переменные и рендер таргеты а "на экране говно", "как же так я тут КУЧУ ТЕСТОВ понаписал, все должно работать!"

Kartonagnick
> Ага, и тесты позволяют ускорить и обезопасить разработку, если поциэнт думает
> об использовании, а не о реализации. Экономит время.
Позволяют если их делать "эффективно" - дешево, сердито и без фанатизма. А TDD вообще очень странная и ограниченно применимая штука, только если что-то совсем простое писать, желательно на Java. )

#53
21:51, 2 фев. 2013

thevlad
> Позволяют если их делать "эффективно" - дешево, сердито и без фанатизма. А TDD
> вообще очень странная и ограниченно применимая штука, только если что-то совсем
> простое писать, желательно на Java. )


Судя по комменту, вы так и не уразумели, что есть TDD. Рекомендую перечитать посты, прочитать литературу.

А судя по вашим прошлым постам: овер-инжениринг ваш друг. Овладев техникой TDD вы сможете минимизировать  овер-инжениринг.

#54
21:58, 2 фев. 2013

thevlad
> "как же так я тут КУЧУ ТЕСТОВ понаписал, все должно работать!"

TDD driven написание шейдеров) Это когда сначала пишешь софтварный рендер, потом к нему поддержку шейдеров, потом кучу тестов для этого рендера и этих шейдеров. И все чтобы шадоумапы работали. А потом опять приходим к "как же так я тут КУЧУ ТЕСТОВ понаписал, все должно работать!" :D In TDD we trust ! :D


Kartonagnick
> Овладев техникой TDD вы сможете минимизировать овер-инжениринг.


См. выше

#55
22:03, 2 фев. 2013

ASD, нужно различать, кто есть поставщик услуг, и как его контролировать.

Если используется сторонняя библиотека-поставщик услуг, то её сопровождение - головная боль её разработчиков.
Программисты компании не тратят времени, что бы писать тесты для стандартных векторов, или тестов опенгл.
Они ожидают получить нужный результат на простых примерах, и усложняют задачу.

Их интересует поведение их кода. А не стороннего.

#56
22:06, 2 фев. 2013

ASD
> См. выше

ваш Ёрик никак не способствует предотвращению овер-инжениринга.

#57
22:07, 2 фев. 2013

Kartonagnick
> Их интересует поведение их кода. А не стороннего.

Правильно, поэтому для чистоты эксперимента они пишут программный рендер. Свой собственный. Чтобы код был свой. На машине у юзера будет говно, зато используется TDD и код тестов в 10 раз длинее кода обычной реализации. Но зато мы проверили что 2+2 = 4. [OK]

#58
22:10, 2 фев. 2013

ASD
> Правильно, поэтому для чистоты эксперимента они пишут программный рендер. Свой
> собственный. Чтобы код был свой. На машине у юзера будет говно, зато
> используется TDD и код тестов в 10 раз длинее кода обычной реализации. Но зато
> мы проверили что 2+2 = 4. [OK]

Зачем писать свой рендер, если нужно получить результат реального рендера?

#59
22:17, 2 фев. 2013

Kartonagnick
> А судя по вашим прошлым постам: овер-инжениринг ваш друг. Овладев техникой TDD
> вы сможете минимизировать  овер-инжениринг.
я вот всегда, если честно грешным делом думал, что овер-инжиниринг возникает когда архитектор "начинает слишком много выдумывать и отрывается от реальности"(или только что прочитал Александреску, тоже вариант), термин "архитектурные астронавты" ни просто так ведь придумали :) и мне почему то кажется что TDD этому будет лишь способствовать, с этим упором на "безупречный дизайн интерфейсов еще не написанного кода".

Страницы: 13 4 5 640 Следующая »
ФлеймФорумПрограммирование

Тема в архиве.