TDD для одного разраба

Если ты знаешь, как писать код - то тесты не нужны.

Неверно.

а как тогда верно?

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

стоп, но ведь сначало нужно писать тест, а потом код. в TDD.

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

стоп, но ведь сначало нужно писать тест, а потом код. в TDD.

А нужен тест для того же. Колдунство.

Его проблема в том, что тесты пишутся для галочки и ценность таких тестов часто меньше, чем при TDD

Ровно наоборот. Когда к тестам отношение более спокойное, для галочки их никто писать не будет. Как раз TDD провоцирует на написание бессмысленных тестов.

Какую ценность tdd привносит для конечного пользователя - это основной критерий.

Например: мантейнеры/разработчики вносят изменения в пакеты (ebuild-ы) или там в расширения, библиотеки - словом модифицируются важные зависимости в итоге.

Соответственно, как не трудно догадаться все восхитительно ломается ;)

Вот тут-то вспоминается tdd ...

В первом случае tdd вообще нет ... Во втором выясняется что есть, но толку ноль ...

Лишь иногда посещает мысль - если бы после изменения прогнали бы набор тестов, может быть что-то срефлексировалось у делальщиков ...

Вывод номер один: как минимум не дурно, когда есть покрытие и его обеспечение ничего не стоит.

К сведению: даже например systemd, облепленный тестами весь такой, а вот толку ... может и не быть.

используй ТДД там, где это необходимо

Так я нигде и не использую.

сегодня на спринте был один пункт, девелопер, который будет его делать - в шоке.

Я предложил ТДД. Они молчат

Спринты — это тот ещё звиздец, но, всё-таки, не настолько.

Помимо очевидных трудозатрат на покрытие тестами всего, TDD дает «иллюзию защищенности», что выливается в более небрежное кодирование («тесты поймают все регрессии!»), что выливается в реальные ошибки, которые должны поймать QA-сотрудники. А если QA уже существует, то нехрен их дублировать.

Автоматизированное тестирование итогового продукта на порядки эффективнее мегабайтов бесполезных юнит-тестов, 95% которых проверяют, что «2+2==4».

я просто оставлю это здесь

Никто здесь не отрицал необходимость тестов.

Любая методология - это не панацея от головотяпства разработчиков. Это способ снизить трудозатраты для ГРАМОТНЫХ разработчиков, которые применяют инструмент корректно.

т.е. важнее не TDD всякие, а способы корректного применения инструментов. Точнее, знания, умения, навыки и корректные их аппликации. Короче, не TDD, а [K(now)]H(ow)DD ;)

ну расскажи мне про TDD Best Practices

Не любая. Только хорошая.

не помнишь известную байку про ремонт пресса, мел, кувалду?

Автоматизированное тестирование итогового продукта на порядки эффективнее мегабайтов бесполезных юнит-тестов, 95% которых проверяют, что «2+2==4».

какие ваши доказательства? и да, расскажи как автоматизированное тестирование итогового продукта упрощает рефакторинг и расширение функциональности, а я послушаю

Нет хороших и плохих. Есть примененные в нужном месте и в нужном виде и нет.

нет

и да, расскажи как автоматизированное тестирование итогового продукта упрощает рефакторинг и расширение функциональности, а я послушаю

Во-первых, регрессии - хер ты юнит тестами посчитаешь. Поведенческое тестирование - то что все юнит тесты зеленые не означает, что все в месте они будут работать. И еще оведрдохрена моментов. Про UI-тестирование вообще молчу.

Во-первых, регрессии - хер ты юнит тестами посчитаешь.

если у тебя есть регрессионный сьют - абсолютно ортогонально, из каких тестов он состоит, уровень тестирования тут не влияет вообще ни на что

Поведенческое тестирование - то что все юнит тесты зеленые не означает, что все в месте они будут работать

если писать их абы как, не покрывая тестами интерфейсы и не понимая, с какими модулями работает модуль under test - не означает. точно так же, как и херово написанный интеграционный тест не показывает ничего.

И еще оведрдохрена моментов

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

Про UI-тестирование вообще молчу

это ты правильно в разговоре о автоматизированной интеграции молчишь о UI. не упоминал бы вообще - за умного сошел бы

если писать их абы как, не покрывая тестами интерфейсы и не понимая, с какими модулями работает модуль under test - не означает. точно так же, как и херово написанный интеграционный тест не показывает ничего.

Ну наконец-то. Хоть пришли к выводу, что все что зависит от человека по факту - ненадежно. И без разницы когда писать тесты до или после кода - результат зависит от автора кода и ничего с этим не сделать.

не упоминал бы вообще - за умного сошел бы

Ой-ли? Если UI присутствует и жизненный цикл сложнее чем «Если видно значит работает, если не видно значит не работает» - без тестирования представления в получится говно.

какие ваши доказательства?

Не намерен ничего доказать любителям assert(2 + 2 == 4)

расскажи как автоматизированное тестирование итогового продукта упрощает рефакторинг и расширение функциональности

Если тебе это не очевидно, то мне очевидно, что с тобой не о чем дальше говорить.

Ну наконец-то. Хоть пришли к выводу, что все что зависит от человека по факту - ненадежно. И без разницы когда писать тесты до или после кода - результат зависит от автора кода и ничего с этим не сделать.

перестань путать TestDriven_Development_ и QA. написание тестов в TDD - способ проектирования и документирования кода. написание тестов в QA - способ найти несоответствие требованиям. ни в одном из вариантов интеграционные тесты не имеют сколько-нибудь значимых преимуществ перед юнит-тестами.

Ой-ли? Если UI присутствует и жизненный цикл сложнее чем «Если видно значит работает, если не видно значит не работает» - без тестирования представления в получится говно.

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

Нет хороших и плохих. Есть примененные в нужном месте и в нужном виде и нет.

Те, для которых программирование — не «нужное место», называются «плохими».

Таких практик практически не существует. У любой есть хоть узкая, но ниша.

перестань путать TestDriven_Development_ и QA

Перестань путать автоматическое тестирование UI и QA, это капец какие разные вещи.

автоматическое тестирование UI - часть QA, TDD и QA - вещи ортогональные. выучи уже матчасть, ньюфажина

автоматическое тестирование UI - часть QA,

facepalm.jpg

немногословненько. ты решил как kawaii_neko, слиться с видом самого умного? в противном случае можно и обширнее возразить

Таких практик практически не существует.

Да почти все такие.

УМВР

немногословненько. ты решил как kawaii_neko, слиться с видом самого умного? в противном случае можно и обширнее возразить

Похапешному хамлу вроде тебя? Да ты половины не поймешь.

Похапешному хамлу

похапешному хамлу можешь не возражать, похапешное хамло с тобой не спорит. а вот мне можешь возразить

ты половины не поймешь

а ты попытайся. за 7 лет в профессии у меня как-то не было проблемы с пониманием QA процессов и терминологии

за 7 лет в профессии у меня как-то не было проблемы

Как это не было. Это я стенке писал? Ньюфажина.

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

Это ты хер знает зачем и к чему написал. расскажи лучше про

автоматическое тестирование UI и QA, это капец какие разные вещи

Можно ещё работать на 286 компах. Тоже будет ВР.

Это ты хер знает зачем и к чему написал. расскажи лучше про

Досвидания.

автоматическое тестирование UI и QA, это капец какие разные вещи

Автоматическое тестирование UI - одна из разновидностей юнит-тестов (те что для V в MVC и для P в MVP) читай техническая проверка реализации. QA - это завершающий этап релиз-цикла, проверяющий соответствие логики проекта и списку фич-реквестов и, внезапно, включающий в себя полный комплекс мер от автоматическоко тестирования до ручного.

Ты тут уже второй, который думает что UI - это <какой-то>эмээль и значит QA.

Досвидания

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

Автоматическое тестирование UI - одна из разновидностей юнит-тестов

если это автоматизированные юнит-тесты на UI. или одна из разновидностей интеграционных тестов, если это интеграционные тесты UI. или одна из разновидностей акцептанс тестов, если это акцептанс тесты UI

читай [техническая] проверка реализации

как и любое [автоматизированное] тестирование. внезапно, да?

QA - это завершающий этап релиз-цикла

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

проверяющий соответствие логики проекта

чему?

списку фич-реквестов

список фич-реквестов не волнует ни QA ни QC. вообще. совсем. он волнует только PM. QA/QC волнет список требований.

внезапно, включающий в себя полный комплекс мер от автоматическоко тестирования до ручного.

внезапно, из этой фразы следует что «автоматическое тестирование UI - часть QA». QA ⊃ QC; QC ⊃ Test automation; Test automation ⊃ UI test automation. сфейспалмируй теперь от своего же высера.

Ты тут уже второй, который думает что UI - это <какой-то>эмээль и значит QA.

а ты один из многотысячного стада баранов, которое думает что задача QA - это запускать тесты и что для QA/QC имеет значение, как именно реализован UI системы - в виде API или HTML. Не говоря уже о том, что твой первоначальный высер про автоматические интеграционные тесты имеет смысл только в разговоре о эмэлях и впфах

как и любое [автоматизированное] тестирование. внезапно, да?

Внезапно нет.

убейся

обратно нет

список фич-реквестов не волнует ни QA ни QC.

Волнует. Это первый критерий качества реализации.

автоматическое тестирование UI - часть QA

Найди в оригинальной фразе «включающий в себя полный комплекс мер от автоматическоко тестирования до ручного» аббревиатуру UI. Нету? А с какого перепугу ты его сюда приплел?

никаким нахер образом не завершающая, а охватывающая весь цикл

И проектирования? И реализации? И качество чего она проверяет? Воздуха? Обещаний?

а ты один из многотысячного стада баранов, которое думает что задача QA - это запускать тесты и что для QA/QC имеет значение, как именно реализован UI системы

Бухой что-ли? Твои слова «автоматическое тестирование UI - часть QA»? Твои. С этого все и началось. Вобщем иди трезвей, пьянь.

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

Нет, работают именно методологии, т.е. без них хуже, чем с ними.

Методолгия работает одна.

Я это вижу постоянно, так как под давлением менеджмента в критических ситуациях иногда приходится что-то выкинуть, в конечном счете это аукается, причем может аукаться годами.

Стопудово. Только методологии от давления менеджмента уж точно не помогают. Особенно если мидл-менеджмент немножко в них понимает и навешать ему лапши не выйдет.

А что, дерево уже реализовал?

давно. уже крутится в продакшене. Клиент за дерево заплатил некислое такое бабло

в следующий раз нужно мне не искать на гитхабе , а реализовывать самому. Через TDD.

Нет, работают именно методологии, т.е. без них хуже, чем с ними.

Методолгия работает одна.

Назови это методологию.

Назови это методологию.

«Пиши, б&%^ь, код».

Назови это методологию.

«Пиши, б&%^ь, код».

Но ведь это стеб, а не методология.