LINUX.ORG.RU

А вы используете TDD в своих проектах?

 


0

3

Не модульные тесты (функциональные, интеграционные), не регресс-тестирование, не test-first, а именно test driven?

Кто-нибудь вообще понимает разницу между этими понятиями?

Странно, что поиск по ЛОРу находит не такие уж древние темы, в которых суровые самоуверенные дядьки только пытаются придумать контраргументы (но не могут, лол). ИРЛ такое сопротивление встречал только в паре контор, что характерно, обе поддерживают цппшные трупопроекты десятилетней давности.

А несколько компаний (в т.ч. довольно серьёзных) в тестовых заданиях вообще указывали обязательно разработку через тестирование проводить.

Почему «гуру программирования» не сумели разобраться в такой простой технологии? Там же вся методика в 100 страницах разжёвана. Неужели туча лишних телодвижений по проектированию и отладке - это действительно так интересно?

★★★

ИМХО сабжевый вопрос можно читать как «А вы быдлокодер?»

в которых суровые самоуверенные дядьки только пытаются придумать контраргументы (но не могут, лол).

сложно объяснить, почему плохо быть быдлокодером. Так надо.

drBatty ★★
()

А вы используете TDD в своих проектах?

Нет, потому что очень редко возникают ситуации, где он принесёт профит.

А несколько компаний (в т.ч. довольно серьёзных) в тестовых заданиях вообще указывали обязательно разработку через тестирование проводить.

Конечно, потому что хорошо для демонстрации.

Там же вся методика в 100 страницах разжёвана

Какие 100 страниц, если там 2 слайда и один пример всё показывают.

quiet_readonly ★★★★
()
Последнее исправление: quiet_readonly (всего исправлений: 1)

какое-то зомбирование без аргументов

nokachi
()

Кто-нибудь вообще понимает разницу между этими понятиями?

Да.

Lorchanin
()

А ты пользовался своими программами ?
Видел живого пользователя Твоего изделия?
Лицом к лицу, хотя бы один на один ?

ilovewindows ★★★★★
()
Последнее исправление: ilovewindows (всего исправлений: 1)

Почему «гуру программирования» не сумели разобраться в такой простой технологии?

Какие гуру?

vurdalak ★★★★★
()
Ответ на: комментарий от quiet_readonly

Какие 100 страниц, если там 2 слайда и один пример всё показывают.

100 страниц для американцев. Две для русск^w всех остальных.

darkenshvein ★★★★★
()

Кто-нибудь вообще понимает разницу между этими понятиями?

Боюсь, только ты.

tailgunner ★★★★★
()
Ответ на: комментарий от ilovewindows

А ты пользовался своими программами ?
Видел живого пользователя Твоего изделия?
Лицом к лицу, хотя бы один на один ?

Конечно. А что?

schizoid ★★★
() автор топика
Ответ на: комментарий от schizoid

очевидно - ты обманываешь себя, доказывается тривиально логикой. солипсистам не поможет, так шо закопайся 8)

Deleted
()

только пытаются придумать контраргументы (но не могут, лол)

Я могу. Это долго. Подходит для одних проектов и не подходит для других, точно так же, как языки программирования и целые платформы.

note173 ★★★★★
()
Ответ на: это оверхед от Deleted

Если совсем без мозгов подходить, то оверхед. Что бы его не было нужно очень много инвестировать, тренироваться и так далее. Собсно проблема исключительно в этом.

dizza ★★★★★
()
Ответ на: комментарий от note173

Подходит для одних проектов и не подходит для других

А есть такие проекты, для которых не подходит ни TDD, ни test-first?

tailgunner ★★★★★
()

не сумели разобраться в такой простой технологии?

Разобраться одно, а начать применять - это практически переучиваться программированию. Как там дядя Боб рассказывал - он свою дочурку научил писать через TDD сразу, так она и не представляет теперь как можно писать по-другому. Так же и те дядьки не представляют как можно писать по-другому :)

dizza ★★★★★
()

Худшие люди - TDDдрочеры, нет им прощения. У них методика - фетиш, к которому они агрессивно склоняют всех

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от tailgunner

А есть такие проекты, для которых не подходит ни TDD, ни test-first?

Например, работа с SQL. Либо ты будешь писать тестовые данные многократно дольше, чем запрос, либо тестировать очень сатный случай.

Вычислительная физика. Вместо тестов инварианты, потому как написать тест для, например, численного решения волновой функции без получения результатов из этого же (или подобного алгоритма) задача неподъёмная.

Интерфейс, веб-сайты: тест = запуск. Написать тест заранее можно, конечно (например, нарисовать в фотошопе и требовать попиксельного соответсвия), но непрактично.

monk ★★★★★
()

это вел ноун вид показухи перед заказчиком в ынтыпрайзе /thread

punya ★★
()
Ответ на: комментарий от tailgunner

Быдлокод на 100000 строчек, в котором новые фичи добавляются авось-где-то-так-driven development. Бизнес требования нужно подтвердить после изменений, что мол все работает как надо. Пример, алгоритм выдает обьект А. Бизнес требования - выдавать обьект Б. Пишем код. Получаем обьект В. Бизнес подверждает что это тоже подходит, даже лучше, они просто не понимали пару нюансов. И так почти всегда

vertexua ★★★★★
()

TDD не работает ни для чего сложнее банального CRUD. Так что пользуются им только в говноконторках. Ты не найдешь TDD на сложных проектах в Microsoft, IBM, Intel и подобных компаниях.

anonymous
()
Ответ на: комментарий от dizza

4.2 милка, трабла в том что «тебе просто банально надо писать раза в два больше кода» и _может_ ты выиграешь на отладке и сопровождении (и то только впиливании новых рюшечек, а рефакторинг может оказаться вдвойне неприятен)

Deleted
()
Ответ на: комментарий от tailgunner

А есть такие проекты, для которых не подходит ни TDD, ни test-first?

Разнообразные морды для веб-сервисов, например, тонкие клиенты БД и т. п. Везде, где промежуточная логика отсутствует.

schizoid ★★★
() автор топика
Ответ на: комментарий от Deleted

тебе просто банально надо писать раза в два больше кода

Тебя расстраивает факт набирания буковок на клавиатуре?

и _может_ ты выиграешь на отладке и сопровождении (и то только впиливании новых рюшечек, а рефакторинг может оказаться вдвойне неприятен)

Да ты и про рефакторинг ничего не знаешь, оказывается. Печалька.

schizoid ★★★
() автор топика

В поиск!

Тема уже поднималась 100500 раз, ищи. [used]dizza вроде говорил, что успешно использовал.

Deleted
()
Ответ на: комментарий от schizoid

Тебя расстраивает факт набирания буковок на клавиатуре?

так тебя держат в центре отк где ты топчешь клаву - мульен тыков в сетки - 3 рубля получил?

Да ты и про рефакторинг ничего не знаешь, оказывается. Печалька.

а мне както за тебя не печально, чем больше таких как ты тем выше моя зарплата - спецы больше ценятся на фоне тебе подобных

Deleted
()
Ответ на: комментарий от monk

веб-сайты

Каждый второй Ruby-on-Rails'щик делал это. Capybara.

Deleted
()
Ответ на: комментарий от Deleted

придется, я исключительно про фанатичное TDD

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

Deleted
()
Ответ на: комментарий от Deleted

но сюда наползли фанатики, которые даже в сортир ходят применяя TDD

Ты там что-то про солипсизм и самообман писал выше.

schizoid ★★★
() автор топика
Ответ на: комментарий от tailgunner

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

Кроме того, не всегда стабильность и отсутствие регрессий являются основными требованиями.

note173 ★★★★★
()

TDD можно НЕ использовать только в прототипах. В остальных случаях - это просто необходимо.

anonymous
()
Ответ на: комментарий от anonymous

Каких фанатиков? Это просто практика. Нет никакого смысла отказываться от TDD, т.е. он не приводит к негативным последствиям. А профит от него весьма ощутим на практике. И, насколько я видел, не применяют его как раз в болотах. Но там и юнит-тесты не пишут. А иногда и VCS не используют...

anonymous
()
Ответ на: комментарий от monk

Например, работа с SQL. Либо ты будешь писать тестовые данные многократно дольше, чем запрос, либо тестировать очень сатный случай.

А как вообще принято проверять сложные запросы?

nikodymus
()
Ответ на: комментарий от vertexua

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

anonymous
()
Ответ на: комментарий от Deleted

Модульные тесты тебе в любом случае придется делать, независимо от того, TDD это или нет.

Модульные тесты можно начинать писать, когда API уже более менее вырисовывается, а при TDD нужно API заранее разработать, написать тесты, написать код, выяснить что всё это ни к чёрту не годится и начать всё с начала. Я такое не осиливаю...

nikodymus
()
Ответ на: комментарий от Deleted

Ну так ты просто не умеешь TDD :)

Кода там не больше, чем при обычном юнит-тестировании с приближением к максимальному покрытию.

Времени ты тратишь не много. Лично я начинаю делать наброски в процессе проектирования... И формализую принятые решения не только на бумажке и UML, но и тестами. Это не так сложно, но приходит не сразу. Ты, видимо, рано сдался. Это может быть признаком развития костности мышления, что нормально с возрастом, но губительно для профессионализма. Задумайся.

anonymous
()
Ответ на: комментарий от nikodymus

Как раз TDD позволит тебе «вырисовывать» API, поскольку фактически они являются первыми клиентами этого самого API. И времени в итоге ты потратишь меньше.

anonymous
()
Ответ на: комментарий от anonymous

Кода там не больше, чем при обычном юнит-тестировании с приближением к максимальному покрытию.

Бугага, дальше можно не читать

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.