Здравствуйте, pagrus, Вы писали:
P>Коллеги,
P>Я читал в книках по agile о том, как тестеры в самом начале итерации могут заняться написанием приёмочных тестов. P>У меня в голове не очень укладывается, как на практике пишется валидный автоматический тест на несуществующую функциональность, которую к тому-же будет разрабатывать кто-то другой.
Пока какой-то функционал еще не реализован, есть возможность разработать тестовый сценарий, так как уже по идее должны быть озвучены какие-то требования/спецификации (разработчики-то на основе чего-то должны реализовывать функционал). А вот уже когда функционал реализован, то можно работать и над реализацией автотеста.
P>Нашёл в гугле и посмотрел пару презентаций по Acceptance TDD — так они обо всём кроме деталей.
P>Можете расписать на пальцах, основываясь на своём опыте? P>* Кто в команде пишет приёмочные тесты? Разработчики, тестеры, product owner?
Могут и те и другие и третьи. Зависит от того, в какой форме эти приемочные тесты представлены. Если это unit-like тесты (реализованы в стиле xUnit движков), то тут скорее работа для разработчиков или же для автоматизаторов (для автоматизации ГУИ как правило задействуется отдельная команда). Но также есть подходы, основная задача которых сводится к предоставлению удобного интерфейса для создания тестов, который понятен и нетехническим специалистам. Примером таких подходов являются keyword-driven, behavior-driven. В этом случае можно привлечь и product-owner-a. Если интересно узнать что-то по этой части, то дополнительно рекомендую погуглить по словам "executable requirements".
P>* Когда? В начале/середине/конце итерации, по мере готовности историй?
Как только есть возможность. То есть, если у вас уже есть требования, спецификации, то можно приступать к созданию тестовых сценариев. Как только готов интерфейс, то уже можно начать реализацию автотестов. Как только функционал достиг хоть какой-то готовности (хотя бы базовый сценарий выполняется), то уже можно и тестировать.
P>* Кто и когда исполняет эти тесты?
Это могут быть тестеры, которым просто нужно дать отмашку, что такой-то функционал готов и его надо бы проверить. Но в том же Agile любят задействовать Continuous Integration, чтобы тесты заводились сами по расписанию (например каждую ночь) или по какому-то триггеру. Даже есть подход, при котором тесты бегают всегда, просто их набор увеличивается по мере добавления новых тестов.
P>* Достигается ли — и каким образом — разработка приёмочных тестов до реализации историй? Давайте предполагать, что команда делает web-приложение.
Достигается. Как я указывал выше, как только есть хоть какая-то порция входных артефактов для создания теста, уже можно работать над какой-то частью реализации теста.
Здравствуйте, pagrus, Вы писали:
P>Можете расписать на пальцах, основываясь на своём опыте? P>* Кто в команде пишет приёмочные тесты? Разработчики, тестеры, product owner?
Тесты могут писать тестировщики/аналитик/менеджер проекта, думаю, сильно зависит от команды
Реализацию тестов могут писать разработчики или тестировщики (если хватает квалификации)
P>* Когда? В начале/середине/конце итерации, по мере готовности историй?
Думаю, чем раньше, тем лучше. Разработчики могут использовать тесты при реализации истории.
P>* Кто и когда исполняет эти тесты?
Тестировщики, разработчики, CI
P>* Достигается ли — и каким образом — разработка приёмочных тестов до реализации историй? Давайте предполагать, что команда делает web-приложение.
При планировании итерации или обсуждении историй тестировщики придумывают приемочные тесты, потом создают описание этих тестов с помощью соответствующих инструментов(например Cucumber или Fitnesse).
Разработчики при реализации истории пишут дополнительный код что-бы тесты могли запускаться(в Fitnesse, например, так называемые fixtures). Разработку кода для тестов можно включить в definition of done, при желании.
Если интересно, посмотрите блог Лизы Криспин, ее команда уже три-четыре года использует ATDD.
Здравствуйте, ulu, Вы писали:
ulu>В TDD все тесты пишутся до реализации, а что в этом такого?
То, что это слишком часто не работает. TDD в классическом виде — это сферический конь в вакууме, применимый только с идеальной задачей, идеальным заказчиком (который никогда не меняет постановку задачу) и идеальными исполнителями (которые всё грамотно спроектировали с самого начала, не махлюют в тестах и не ошибаются в реализации). В более типичном случае всегда есть места, которые переделываются по 2-3 раза, включая внутренние интерфейсы, код пишется раньше тестов для того, чтобы проверить, что он в принципе работает, и уже после получения работающего результата возникает понимание, что надо было делать и почему именно так. В этом случае TDD в принципе непригоден. А если вмешивается заказчик, заставляя всё перепахать, то от его обоснований вообще ничего не остаётся.
Правило "сначала тест, потом код" в TDD имеет два смысла. Первый — административный — выполнение такого рода процедуры проще обеспечить и соблюсти общий порядок, чем, если код уже написан, тянуть со временем и с деньгами, чтобы выдать релиз ("чего вы тянете, оно же всё написано и у тестера Маши даже показало результат! немедленно начинать продавать!") Второй — это хоть какая-то надёжность работы самого теста. Первое я ещё могу принять как обоснование, второе — нет, потому что неизвестно качество самого теста: например, он может проверять, что функция вообще реализована, но соглашаться на любое возвращённое значение, независимо от его корректности. С минимальным тестовым фреймворком замаскировать такую облегчённую проверку тривиально, и требуется явный code review кем-то заинтересованным в качестве реализации, чтобы проверки были реальными. Но, заметьте, TDD этого (ревью кода тестов) в общем случае не требует, а косвенно, наоборот, обещает (для стандартной психологии менеджера), что code review при TDD нужен меньше — потому что всё покрыто тестами.
Мы для обеспечения корректности тестов используем инверсии тестов. Инверсия — это запуск при специальном входном условии (параметре) самого теста, которое требует выполнить изменение входных данных проверяемого кода с тем, чтобы результат не соответствовал ожидаемому без инверсии. Например, если проверяется сложение строк, на входе 2 строки по 40 символов, а на выходе 80, то инверсией может быть задание пустой строки вместо второй. (В реальности примеры сильно сложнее: например, один из тестов — порвать связь с объектом и проверить, что первая тревога уровня warning прошла в интервале от 9 до 15 секунд; тогда инверсия — не рвать связь.) Тест корректен, если он выполняется положительно без инверсий со всеми вариациями и отрицательно — при любой из инверсий. Проверки, список вариаций и инверсий входят в спецификацию теста и соответствие им проверяется через явное ревью кода теста.
ulu> Ведь смысл тестов в том, чтобы помочь реализации, так?
ulu>Web-приложения -- не исключение. Вы даете браузеру задание ввести текст в поле "Name" и нажать кнопку "OK", а потом проверяете результат. Понятно, что тест упадет -- ведь такого поля и кнопки нет. Как раз непонятно, как в этой ситуации делать ручные тесты.
Проверить, что кнопки нет. По-моему, это очевидно. Точно так же как нелепость такого теста по отдельности в случае ручного запуска.
Во-первых, возможно, как раз такие приемочные тесты (которые пишутся до кода) стоит писать самим разработчикам? Во-вторых, по поводу таких деталей, как названия полей, можно ведь наладить коммуникацию между разработчиками и тестировщиками?
Здравствуйте, pagrus, Вы писали:
P>Здравствуйте, ulu, Вы писали:
ulu>>В TDD все тесты пишутся до реализации, а что в этом такого? Ведь смысл тестов в том, чтобы помочь реализации, так? P>Да, но ведь в TDD разработчик и пишет тест, и задаёт сигнатуры тестируемого объекта. P>Здесь же тестер пишет приёмочные тесты, в то время как разработчик занимается реализацией функциональности. Как поддерживается ожидаемый с обоих сторон интерфейс между тестом и реализацией?
ulu>>Web-приложения -- не исключение. Вы даете браузеру задание ввести текст в поле "Name" и нажать кнопку "OK", а потом проверяете результат. Понятно, что тест упадет -- ведь такого поля и кнопки нет. Как раз непонятно, как в этой ситуации делать ручные тесты.
P>Вот. Как тестер знает, что поле будет называться "Name", а не "LastName"? Что будет кнопка, а не линк? Что текст будет "OK", а не "Next"? Как он в условиях неопределённости сделает извлечение результата для последующей проверки?
P>Или идея в том, что именно тестер _специфицирует_ эти технические детали, тогда как разрабочик должен извлечь их из кода приёмочного теста, и потом уложиться в них?
P>Или разработка приёмочного теста проходит в два этапа P>1. Написали каркас P>2. Допилили под специфику реализации P>?
ulu>>Web-приложения -- не исключение. Вы даете браузеру задание ввести текст в поле "Name" и нажать кнопку "OK", а потом проверяете результат. Понятно, что тест упадет -- ведь такого поля и кнопки нет. Как раз непонятно, как в этой ситуации делать ручные тесты.
P>Вот. Как тестер знает, что поле будет называться "Name", а не "LastName"? Что будет кнопка, а не линк? Что текст будет "OK", а не "Next"? Как он в условиях неопределённости сделает извлечение результата для последующей проверки?
Приемочные тесты не имеют отношения к дизайну и не должны быть детализированы до кнопок и полей. Их смысл — иметь общее направление и четкий критерий окончания реализации функциональности — конечную точку, куда нужно двигаться. А вот как достичь этой точки, покажут юнит-тесты, они сформируют дизайн. Вот хороший пост по теме.
В TDD все тесты пишутся до реализации, а что в этом такого? Ведь смысл тестов в том, чтобы помочь реализации, так?
Web-приложения -- не исключение. Вы даете браузеру задание ввести текст в поле "Name" и нажать кнопку "OK", а потом проверяете результат. Понятно, что тест упадет -- ведь такого поля и кнопки нет. Как раз непонятно, как в этой ситуации делать ручные тесты.
Здравствуйте, pagrus, Вы писали:
P>Коллеги,
P>Я читал в книках по agile о том, как тестеры в самом начале итерации могут заняться написанием приёмочных тестов. P>У меня в голове не очень укладывается, как на практике пишется валидный автоматический тест на несуществующую функциональность, которую к тому-же будет разрабатывать кто-то другой.
P>Нашёл в гугле и посмотрел пару презентаций по Acceptance TDD — так они обо всём кроме деталей.
P>Можете расписать на пальцах, основываясь на своём опыте? P>* Кто в команде пишет приёмочные тесты? Разработчики, тестеры, product owner? P>* Когда? В начале/середине/конце итерации, по мере готовности историй? P>* Кто и когда исполняет эти тесты? P>* Достигается ли — и каким образом — разработка приёмочных тестов до реализации историй? Давайте предполагать, что команда делает web-приложение.
P>спасибо
N>То, что это слишком часто не работает. TDD в классическом виде — это сферический конь в вакууме, применимый только с идеальной задачей, идеальным заказчиком (который никогда не меняет постановку задачу) и идеальными исполнителями (которые всё грамотно спроектировали с самого начала, не махлюют в тестах и не ошибаются в реализации).
Это не так, а как раз наоборот. Юнит тесты особенно хорошо показывают свою ценность именно в условиях постоянных доработок проекта и изменения требований, потому что дают уверенность в качестве кода и делают рефакторинг простой и быстрой задачей.
N>В более типичном случае всегда есть места, которые переделываются по 2-3 раза, включая внутренние интерфейсы, код пишется раньше тестов для того, чтобы проверить, что он в принципе работает, и уже после получения работающего результата возникает понимание, что надо было делать и почему именно так. В этом случае TDD в принципе непригоден.
Вы путаете TDD с бардаком, когда нет планирования и постоянного feedback от заказчика, либо когда из всего процесса TDD берут одни только юнит-тесты и пытаются прикрутить их к legacy проекту.
N>А если вмешивается заказчик, заставляя всё перепахать, то от его обоснований вообще ничего не остаётся.
На практике вариант "все переделать с нуля" как правило не встречается, а если встречается, то с заказчиком заключается новый договор на разработку новой программы. Что происходит в реальности, это "что-то писали в течение года, потом показали заказчику и оказалось, что за год бизнес-задачи поменялись, на момент составления ТЗ заказчик сам не до конца понимал чего ему нужно, а программисты это еще и не так интерпретировали". TDD не поможет при неправильном применении.
N>Правило "сначала тест, потом код" в TDD имеет два смысла. Первый — административный — выполнение такого рода процедуры проще обеспечить и соблюсти общий порядок, чем, если код уже написан, тянуть со временем и с деньгами, чтобы выдать релиз ("чего вы тянете, оно же всё написано и у тестера Маши даже показало результат! немедленно начинать продавать!")
Какое отношение имеют юнит тесты с "показало результат"? Ладно бы функциональные или приемочные, но юнит тесты?
N>Второй — это хоть какая-то надёжность работы самого теста.
Да, одно из преимуществ написания теста до кода — это возможность убедиться в том, что тест способен валиться. Иначе легко получить тесты, которые проходят вообще всегда, независимо от качества реализации тестируемой функции.
N>Первое я ещё могу принять как обоснование, второе — нет, потому что неизвестно качество самого теста: например, он может проверять, что функция вообще реализована, но соглашаться на любое возвращённое значение, независимо от его корректности.
Если тест стал настолько сложным, что в нем легко допустить такую ошибку, значит либо это не юнит-тест, а функциональный тест, либо пора думать о тестах для тестов, т.е. о создании упрощенной модели тестируемого продукта, на которой можно отлаживать тесты.
N>Но, заметьте, TDD этого (ревью кода тестов) в общем случае не требует, а косвенно, наоборот, обещает (для стандартной психологии менеджера), что code review при TDD нужен меньше — потому что всё покрыто тестами.
TDD ничего подобного не обещает. На самом деле разработка с TDD сложнее, чем без TDD. Это та цена, которую мы платим за предсказуемость результат и уменьшение времени отладки. Те, кто считает, что с TDD можно будет ничего не делать и писать код тяп-ляп, а оно как-нибудь само, сильно заблуждаются.
N>Мы для обеспечения корректности тестов используем инверсии тестов. Инверсия — это запуск при специальном входном условии (параметре) самого теста, которое требует выполнить изменение входных данных проверяемого кода с тем, чтобы результат не соответствовал ожидаемому без инверсии. Например, если проверяется сложение строк, на входе 2 строки по 40 символов, а на выходе 80, то инверсией может быть задание пустой строки вместо второй. (В реальности примеры сильно сложнее: например, один из тестов — порвать связь с объектом и проверить, что первая тревога уровня warning прошла в интервале от 9 до 15 секунд; тогда инверсия — не рвать связь.) Тест корректен, если он выполняется положительно без инверсий со всеми вариациями и отрицательно — при любой из инверсий. Проверки, список вариаций и инверсий входят в спецификацию теста и соответствие им проверяется через явное ревью кода теста.
Здравствуйте, abibok, Вы писали:
N>>То, что это слишком часто не работает. TDD в классическом виде — это сферический конь в вакууме, применимый только с идеальной задачей, идеальным заказчиком (который никогда не меняет постановку задачу) и идеальными исполнителями (которые всё грамотно спроектировали с самого начала, не махлюют в тестах и не ошибаются в реализации). A>Это не так, а как раз наоборот. Юнит тесты особенно хорошо показывают свою ценность именно в условиях постоянных доработок проекта и изменения требований, потому что дают уверенность в качестве кода и делают рефакторинг простой и быстрой задачей.
Я говорил про TDD, а Вы начали про юнит-тесты в целом. Вы не замечаете подмены тезиса со своей стороны?
N>>В более типичном случае всегда есть места, которые переделываются по 2-3 раза, включая внутренние интерфейсы, код пишется раньше тестов для того, чтобы проверить, что он в принципе работает, и уже после получения работающего результата возникает понимание, что надо было делать и почему именно так. В этом случае TDD в принципе непригоден. A>Вы путаете TDD с бардаком,
Нет, не путаю. Читайте внимательно. Я, наоборот, говорил, что для эффективного применения TDD необходимым условием является высококачественное планирование, умный заказчик, который знает, чего хочет, изначально правильная архитектурная разработка (что может определиться только постфактум) и, возможно, другие столь же нетипичные условия. В более реальных условиях он перестаёт работать, и от него остаются только лулзы для менеджера.
A> когда нет планирования и постоянного feedback от заказчика,
А даже если планирование есть, чем оно поможет, если заказчик изменил требования?
A> либо когда из всего процесса TDD берут одни только юнит-тесты и пытаются прикрутить их к legacy проекту.
О да. Это не царь-батюшка плохой, это бояре его волю переврали.
N>>А если вмешивается заказчик, заставляя всё перепахать, то от его обоснований вообще ничего не остаётся. A>На практике вариант "все переделать с нуля" как правило не встречается, а если встречается, то с заказчиком заключается новый договор на разработку новой программы. Что происходит в реальности, это "что-то писали в течение года, потом показали заказчику и оказалось, что за год бизнес-задачи поменялись, на момент составления ТЗ заказчик сам не до конца понимал чего ему нужно, а программисты это еще и не так интерпретировали".
Хм. Кто-то говорил только что о правильном планировании и взаимодействии с заказчиком, а теперь рассказывает про то, что показал что-то через год?
N>>Правило "сначала тест, потом код" в TDD имеет два смысла. Первый — административный — выполнение такого рода процедуры проще обеспечить и соблюсти общий порядок, чем, если код уже написан, тянуть со временем и с деньгами, чтобы выдать релиз ("чего вы тянете, оно же всё написано и у тестера Маши даже показало результат! немедленно начинать продавать!") A>Какое отношение имеют юнит тесты с "показало результат"? Ладно бы функциональные или приемочные, но юнит тесты?
Самое прямое. Юнит-тест — это функциональный тест для компоненты нижнего уровня (функции, класса). Показало результат — это показало соответствие кода ожиданиям этого теста.
Если Вы решили прочесть "показало результат" как "показало заказчику результат" (или хотя бы приёмке верхнего уровня), то это чисто Ваши домыслы, для которых нет основания в моих словах.
N>>Второй — это хоть какая-то надёжность работы самого теста. A>Да, одно из преимуществ написания теста до кода — это возможность убедиться в том, что тест способен валиться. Иначе легко получить тесты, которые проходят вообще всегда, независимо от качества реализации тестируемой функции.
То, что Вы говорите — расхожий миф, исходящий из авторов красивых книг и не имеющий никакого отношения к реальности. Да, написать тест, который зовёт функцию и проверяет результат — это гарантированный способ сломать тест, пока функции ещё нет. Но если тест, например, проверяет, что функция вообще что-то вернула, но игнорирует её значение, то он окажется удовлетворённым при любой реализации функции. Если реализатор работает честно, то он такого не сделает. Но если нет, то он тривиально подсунет фактическую непроверку результата (а при достаточном навыке и замаскировав отсутствие проверки). Значит, всё равно нужно ревью кода. А если делается ревью, то ревьюер и способен проверить как наличие тестов, так и их реальное выполнение. А бесконтрольное соответствие принципу "сначала тест, потом код" без оценки качества кода и теста — ничего не даёт, кроме уже описанного мной ранее средства самоорганизации (тест является видимой и описанной целью, требующей удовлетворения).
N>>Первое я ещё могу принять как обоснование, второе — нет, потому что неизвестно качество самого теста: например, он может проверять, что функция вообще реализована, но соглашаться на любое возвращённое значение, независимо от его корректности. A>Если тест стал настолько сложным, что в нем легко допустить такую ошибку,
Такую ошибку или намеренную диверсию возможно допустить независимо от сложности теста.
A> значит либо это не юнит-тест, а функциональный тест,
Я не признаю ту систему терминов, в которой между юнит-тестами и функциональными тестами есть жёсткая граница. Функциональный тест в случае одной функции без побочных эффектов "вырождается" в юнит-тест.
A> либо пора думать о тестах для тестов, т.е. о создании упрощенной модели тестируемого продукта, на которой можно отлаживать тесты.
В следующем комментарии я как раз и рассказывал про тесты для тестов, но без модели тестируемого.
N>>Но, заметьте, TDD этого (ревью кода тестов) в общем случае не требует, а косвенно, наоборот, обещает (для стандартной психологии менеджера), что code review при TDD нужен меньше — потому что всё покрыто тестами. A>TDD ничего подобного не обещает. На самом деле разработка с TDD сложнее, чем без TDD.
Во-первых, не вижу обоснования этому тезису (что она сложнее). Во-вторых, кому Вы возражаете? Я не говорил, что она с ним проще.
A> Это та цена, которую мы платим за предсказуемость результат и уменьшение времени отладки. Те, кто считает, что с TDD можно будет ничего не делать и писать код тяп-ляп, а оно как-нибудь само, сильно заблуждаются.
С какой ветряной мельницей Вы спорили на этот раз?
N>>Мы для обеспечения корректности тестов используем инверсии тестов. Инверсия — это запуск при специальном входном условии (параметре) самого теста, которое требует выполнить изменение входных данных проверяемого кода с тем, чтобы результат не соответствовал ожидаемому без инверсии. Например, если проверяется сложение строк, на входе 2 строки по 40 символов, а на выходе 80, то инверсией может быть задание пустой строки вместо второй. (В реальности примеры сильно сложнее: например, один из тестов — порвать связь с объектом и проверить, что первая тревога уровня warning прошла в интервале от 9 до 15 секунд; тогда инверсия — не рвать связь.) Тест корректен, если он выполняется положительно без инверсий со всеми вариациями и отрицательно — при любой из инверсий. Проверки, список вариаций и инверсий входят в спецификацию теста и соответствие им проверяется через явное ревью кода теста.
A>Это — не юнит-тесты.
Ну и что с того? Я не вижу причины ограничивать рассмотрение этих механизмов тестами минимальных компонент.
Я читал в книках по agile о том, как тестеры в самом начале итерации могут заняться написанием приёмочных тестов.
У меня в голове не очень укладывается, как на практике пишется валидный автоматический тест на несуществующую функциональность, которую к тому-же будет разрабатывать кто-то другой.
Нашёл в гугле и посмотрел пару презентаций по Acceptance TDD — так они обо всём кроме деталей.
Можете расписать на пальцах, основываясь на своём опыте?
* Кто в команде пишет приёмочные тесты? Разработчики, тестеры, product owner?
* Когда? В начале/середине/конце итерации, по мере готовности историй?
* Кто и когда исполняет эти тесты?
* Достигается ли — и каким образом — разработка приёмочных тестов до реализации историй? Давайте предполагать, что команда делает web-приложение.
Здравствуйте, pagrus, Вы писали:
P>Коллеги,
P>Я читал в книках по agile о том, как тестеры в самом начале итерации могут заняться написанием приёмочных тестов. P>У меня в голове не очень укладывается, как на практике пишется валидный автоматический тест на несуществующую функциональность, которую к тому-же будет разрабатывать кто-то другой.
На практике я думаю никто этим не занимается. Agile придумали теоретики для теоретиков, на практике все эти методологии надо допиливать напильником. Главное, чтобы было что допиливать, то есть была процедура и она выполнялась, иначе будет хаос и управление проектом будет затруднительно.
В реальности, я бы описал "ручные" тесты в общих чертах, неформально.
Здравствуйте, pagrus, Вы писали:
P>Я читал в книках по agile о том, как тестеры в самом начале итерации могут заняться написанием приёмочных тестов. P>У меня в голове не очень укладывается, как на практике пишется валидный автоматический тест на несуществующую функциональность, которую к тому-же будет разрабатывать кто-то другой.
Приемочный тест — это не обязательно автоматический тест.
L>Приемочный тест — это не обязательно автоматический тест.
Это правда. Хотя меня в первую очередь интересуют именно автоматизированные приёмочные тесты, ответ на вопросы в контексте ручных тестов тоже приветствуется.
Здравствуйте, pagrus, Вы писали:
L>>Приемочный тест — это не обязательно автоматический тест.
P>Это правда. Хотя меня в первую очередь интересуют именно автоматизированные приёмочные тесты, ответ на вопросы в контексте ручных тестов тоже приветствуется.
Я понимаю. Но авторы, которых вы упомянули, скорее всего имели в виду ручные тесты.
Здравствуйте, ulu, Вы писали:
ulu>В TDD все тесты пишутся до реализации, а что в этом такого? Ведь смысл тестов в том, чтобы помочь реализации, так?
Да, но ведь в TDD разработчик и пишет тест, и задаёт сигнатуры тестируемого объекта.
Здесь же тестер пишет приёмочные тесты, в то время как разработчик занимается реализацией функциональности. Как поддерживается ожидаемый с обоих сторон интерфейс между тестом и реализацией?
ulu>Web-приложения -- не исключение. Вы даете браузеру задание ввести текст в поле "Name" и нажать кнопку "OK", а потом проверяете результат. Понятно, что тест упадет -- ведь такого поля и кнопки нет. Как раз непонятно, как в этой ситуации делать ручные тесты.
Вот. Как тестер знает, что поле будет называться "Name", а не "LastName"? Что будет кнопка, а не линк? Что текст будет "OK", а не "Next"? Как он в условиях неопределённости сделает извлечение результата для последующей проверки?
Или идея в том, что именно тестер _специфицирует_ эти технические детали, тогда как разрабочик должен извлечь их из кода приёмочного теста, и потом уложиться в них?
Или разработка приёмочного теста проходит в два этапа
1. Написали каркас
2. Допилили под специфику реализации
?
ulu>Во-первых, возможно, как раз такие приемочные тесты (которые пишутся до кода) стоит писать самим разработчикам? Во-вторых, по поводу таких деталей, как названия полей, можно ведь наладить коммуникацию между разработчиками и тестировщиками?
VS>Приемочные тесты не имеют отношения к дизайну и не должны быть детализированы до кнопок и полей. Их смысл — иметь общее направление и четкий критерий окончания реализации функциональности — конечную точку, куда нужно двигаться.
Ок, а вы говорите про автоматизированные, исполняемые тесты? Или полуформализованное описание, направленное на человека?
Со вторым никаких вопросов нет; мой вопрос был о том, действительно ли можно написать исполняемый acceptance test до кода.
VS>А вот как достичь этой точки, покажут юнит-тесты, они сформируют дизайн. Вот хороший пост по теме.
Пардон, статью по ссылке не понял. Он вероятно предполагает хорошее понимание фреймворка, у меня этого нет.
P>>* Кто в команде пишет приёмочные тесты? Разработчики, тестеры, product owner? N>Тесты могут писать тестировщики/аналитик/менеджер проекта, думаю, сильно зависит от команды N>Реализацию тестов могут писать разработчики или тестировщики (если хватает квалификации)
Т.е. вы говорите о "тестах" как простом человеческом описании шагов, проверяющих историю.
И о "реализации тестов" как автоматизированной проверке этих шагов.
P>>* Когда? В начале/середине/конце итерации, по мере готовности историй? N>Думаю, чем раньше, тем лучше. Разработчики могут использовать тесты при реализации истории.
Как я понимаю, здесь вы снова говорите о текстовом описании шагов? Иначе снова возникает вопрос написания исполняемого теста до релизации.
P>>* Кто и когда исполняет эти тесты? N>Тестировщики, разработчики, CI
А тут речь уже про автоматический тест. Не вполне стыкуется — по крайней мере у меня в голове.
P>>* Достигается ли — и каким образом — разработка приёмочных тестов до реализации историй? Давайте предполагать, что команда делает web-приложение. N>При планировании итерации или обсуждении историй тестировщики придумывают приемочные тесты, потом создают описание этих тестов с помощью соответствующих инструментов(например Cucumber или Fitnesse). N>Разработчики при реализации истории пишут дополнительный код что-бы тесты могли запускаться(в Fitnesse, например, так называемые fixtures). Разработку кода для тестов можно включить в definition of done, при желании.
Иными словами, тестировщик пишет "каркас" теста, а разработчик добавляет детали, чтобы тест стал исполняемым? Это я могу представить.
N>Если интересно, посмотрите блог Лизы Криспин, ее команда уже три-четыре года использует ATDD.
Интересно. Я как раз читаю "Agile Testing", где она соавтор. Спасибо.
Так вышло, что уже после начала этого топика я прошёл certified scrummaster у хорошего тренера, и теперь думаю что в самом вопросе заложены некорректные предпосылки.
— что в agile-команде выделяются разработчики и тестеры
— что вторые должны обеспечивать тестирование работы первых и никак иначе
— что приёмочный тест обязательно автоматизирован
— что автоматизированный приёмочный тест разрабатывается в полном объёме одним человеком, а затем в готовом виде "перебрасывается через забор" разработчику
Здравствуйте, pagrus, Вы писали:
P>Коллеги,
P>Я читал в книках по agile о том, как тестеры в самом начале итерации могут заняться написанием приёмочных тестов. P>У меня в голове не очень укладывается, как на практике пишется валидный автоматический тест на несуществующую функциональность,
Почитайте про behavior driven development. Это частный, но яркий случай такого подхода. Если какая-то функциональность оговорена изначальной постановкой задачи, и она пригодна к автоматической проверке, то на неё можно написать тест ещё до реализации. Возможно, какие-то детали этого теста могут быть изменены позже (например, несущественное изменение порядка действий или даже аргументов в вызове функции), но основная интеллектуальная работа к этому моменту уже проделана и доработать можно относительно легко.
P> которую к тому-же будет разрабатывать кто-то другой.
А это как раз важный приём: написание тестов не автором кода позволяет применить мышление, которое не шло по известному проторенному пути и может создавать неожиданные проверки. Хотя это более полезно для особо хитрых внутренностей.
N>Почитайте про behavior driven development. Это частный, но яркий случай такого подхода. Если какая-то функциональность оговорена изначальной постановкой задачи, и она пригодна к автоматической проверке, то на неё можно написать тест ещё до реализации. Возможно, какие-то детали этого теста могут быть изменены позже (например, несущественное изменение порядка действий или даже аргументов в вызове функции), но основная интеллектуальная работа к этому моменту уже проделана и доработать можно относительно легко.
P>> которую к тому-же будет разрабатывать кто-то другой.
N>А это как раз важный приём: написание тестов не автором кода позволяет применить мышление, которое не шло по известному проторенному пути и может создавать неожиданные проверки. Хотя это более полезно для особо хитрых внутренностей.
Спасибо, про BDD я читал и даже слегка использую при юнит-тестировании. Нормально работает, когда я по ходу написания тестов могу добавлять сигнатуры основного кода.
Непонятно, как это работает в случае написания приёмочных тестов другим человеком, до кода. Для того, чтобы они были исполняемыми, нужно знать реализацию, по крайней мере на уровне интерфейса. А его пока нет.
Интересная мысль про инверсию тестов. Я похожее делаю вручную при реализации тестов/кода, особенно если вдруг неожиданно много новых тестов прошли с первого раза.
Я правильно понимаю, что такие инверсии вы оформляете как отдельные тест-кейсы и включаете в общий test suite?
Здравствуйте, pagrus, Вы писали:
P>Интересная мысль про инверсию тестов. Я похожее делаю вручную при реализации тестов/кода, особенно если вдруг неожиданно много новых тестов прошли с первого раза.
P>Я правильно понимаю, что такие инверсии вы оформляете как отдельные тест-кейсы и включаете в общий test suite?
Да.
Технологически это выглядит как включение каталога в список тех, у которых есть инверсии, и задание списка опций в параметре FUNCTESTS_INVERSE в Makefile. Включаемый в это Makefile файл умеет итерировать этот список и запускать тест с установкой параметра в окружении.
Единственное специфическое ограничение метода — сама проверка параметра и действия в его случае не должны сами приводить к слёту теста; отличить эту ситуацию в многомегабайтной простыне тяжело. Но такое условие достаточно легко обеспечить и мы с ним смирились.
N>>>То, что это слишком часто не работает. TDD в классическом виде — это сферический конь в вакууме, применимый только с идеальной задачей, идеальным заказчиком (который никогда не меняет постановку задачу) и идеальными исполнителями (которые всё грамотно спроектировали с самого начала, не махлюют в тестах и не ошибаются в реализации). A>>Это не так, а как раз наоборот. Юнит тесты особенно хорошо показывают свою ценность именно в условиях постоянных доработок проекта и изменения требований, потому что дают уверенность в качестве кода и делают рефакторинг простой и быстрой задачей.
N>Я говорил про TDD, а Вы начали про юнит-тесты в целом. Вы не замечаете подмены тезиса со своей стороны?
Хорошо, у вас был опыт применения TDD на реальном проекте? С какими трудностями столкнулись? Почему считаете, что TDD не работает? Я стал говорить о юнит-тестах, потому что это один из ключевых компонентов TDD. В данном случае в моей фразе все слова "юнит тесты" можно заменить на "TDD", от этого смысл не изменится, просто постановка вопроса станет более общей. Если хотите еще шире, то замените "TDD" на "XP".
N>Я, наоборот, говорил, что для эффективного применения TDD необходимым условием является высококачественное планирование,
Да, но не в привычном waterfall стиле.
N>умный заказчик, который знает, чего хочет
Это не обязательно. Большинство заказчиков не способны четко и исчерпывающе сформулировать ТЗ в начале проекта. TDD как раз помогает работать с такими реальными заказчиками.
N>изначально правильная архитектурная разработка (что может определиться только постфактум)
Это тоже не обязательно. TDD позволяет изменять архитектуру в процессе работы, не боясь что проект станет нестабильным и все начнет сыпаться. Разумеется, это не относится к ключевым решениям самого высокого уровня. У TDD есть свои пределы масштабирования, это хорошо известно.
N>В более реальных условиях он перестаёт работать, и от него остаются только лулзы для менеджера.
Если менеджер не имеет опыта применения TDD, но с горящими глазами бросился внедрять новую игрушку, прочитав пару статей на тему, то да — игрушкой и останется. В противном случае, да еще и в условиях высокой дисциплины разработки в команде, TDD не то что хорошо работает, а даже я бы сказал является незаменимой техникой. Как нельзя программировать без классов, так нельзя делать проекты без TDD.
N>А даже если планирование есть, чем оно поможет, если заказчик изменил требования?
Если планирование есть, то проект может получиться, а может провалиться. А вот если планирования нет, то начиная с определенного уровня сложности проект обречен на провал. Планирование само себе не гарантирует успеха, но является его необходимым требованием. У нас говорят "Failing to plan is planning to fail" и я сам не раз убеждался, что скорость кодирования или индивидуальное мастерство программистов стоят далеко не на первом месте и важны куда менее, чем грамотное планирование и хороший communication.
A>> либо когда из всего процесса TDD берут одни только юнит-тесты и пытаются прикрутить их к legacy проекту. N>О да. Это не царь-батюшка плохой, это бояре его волю переврали.
При чем здесь царь и бояре? TDD — достаточно сложная и имеющая массу нюансов при практическом применении техника. Если вы вдруг решили написать сотню тестов в готовом проекте, то это что угодно, кроме TDD.
N>>>А если вмешивается заказчик, заставляя всё перепахать, то от его обоснований вообще ничего не остаётся. A>>На практике вариант "все переделать с нуля" как правило не встречается, а если встречается, то с заказчиком заключается новый договор на разработку новой программы. Что происходит в реальности, это "что-то писали в течение года, потом показали заказчику и оказалось, что за год бизнес-задачи поменялись, на момент составления ТЗ заказчик сам не до конца понимал чего ему нужно, а программисты это еще и не так интерпретировали".
N>Хм. Кто-то говорил только что о правильном планировании и взаимодействии с заказчиком, а теперь рассказывает про то, что показал что-то через год?
Читайте внимательно. "Показали через год" — это негативный пример, который показывает как делать не надо. TDD здесь и не пахнет, даже если разработчики пытались писать какие-то тесты.
N>>>Правило "сначала тест, потом код" в TDD имеет два смысла. Первый — административный — выполнение такого рода процедуры проще обеспечить и соблюсти общий порядок, чем, если код уже написан, тянуть со временем и с деньгами, чтобы выдать релиз ("чего вы тянете, оно же всё написано и у тестера Маши даже показало результат! немедленно начинать продавать!") A>>Какое отношение имеют юнит тесты с "показало результат"? Ладно бы функциональные или приемочные, но юнит тесты?
N>Самое прямое. Юнит-тест — это функциональный тест для компоненты нижнего уровня (функции, класса). Показало результат — это показало соответствие кода ожиданиям этого теста.
Простите, но у вас каша в голове. Начиная с того, что тестеры не занимаются написанием и выполнением юнит-тестов и заканчивая смешивание понятий функционального и юнит тестов. То что в проекте успешно проходят юнит тесты абсолютно ничего не говорит о пригодности проекта к релизу или даже к способности проекта выполнять хотя бы какой-то полезный для заказчика функционал. "Проходимость" юнит-тестов — это, пожалуй, наименее информативная из всех метрик. Можете повесить на стенку мраморную табличку, где будет выбита прямая линия и написано "Pass — 100%". Эта табличка будет актуальна для любого проекта на многие годы просто потому что такова природа юнит-тестов, они всегда проходят на 100%.
N>>>Второй — это хоть какая-то надёжность работы самого теста. A>>Да, одно из преимуществ написания теста до кода — это возможность убедиться в том, что тест способен валиться. Иначе легко получить тесты, которые проходят вообще всегда, независимо от качества реализации тестируемой функции.
N>То, что Вы говорите — расхожий миф, исходящий из авторов красивых книг и не имеющий никакого отношения к реальности.
Расскажите как обстоят дела в вашей реальности.
N>Да, написать тест, который зовёт функцию и проверяет результат — это гарантированный способ сломать тест, пока функции ещё нет. Но если тест, например, проверяет, что функция вообще что-то вернула, но игнорирует её значение, то он окажется удовлетворённым при любой реализации функции.
Тест должен сначала не пройти, а потом, после реализации функции или исправлении бага — пройти. Принципиальное значение имеет факт такого перехода от fail к pass, а не просто "всегда fail" или "всегда pass".
N>Если реализатор работает честно, то он такого не сделает. Но если нет, то он тривиально подсунет фактическую непроверку результата (а при достаточном навыке и замаскировав отсутствие проверки). Значит, всё равно нужно ревью кода.
TDD не гарантирует отсутствия ошибок в юнит-тестах. Такое вполне себе встречается, юнит-тесты — это такой же код и пишут его те же несовершенные люди. Как и любой код, юнит-тесты требуют code review при первом сабмите и позже при любых изменениях.
N>А бесконтрольное соответствие принципу "сначала тест, потом код" без оценки качества кода и теста — ничего не даёт
С чего вы взяли что такой подход будет называться TDD? Кто сказал, что написание тестов позволит обходиться без оценки качества?
N>кроме уже описанного мной ранее средства самоорганизации (тест является видимой и описанной целью, требующей удовлетворения).
Маленькие дети, когда не хотят делать уроки, начинают раскладывать на столе тетрадки, точить карандаши и прочими способами имитировать бурную деятельность. Лишь бы не работать. Так и здесь, если вам необходимо нечто, о чем можно отчитаться начальству как о внедрении и средстве самоорганизации — ок, но не говорите потом что TDD не работает, потому что такое применение — это не TDD.
N>>>Но, заметьте, TDD этого (ревью кода тестов) в общем случае не требует, а косвенно, наоборот, обещает (для стандартной психологии менеджера), что code review при TDD нужен меньше — потому что всё покрыто тестами. A>>TDD ничего подобного не обещает. На самом деле разработка с TDD сложнее, чем без TDD. N>Во-первых, не вижу обоснования этому тезису (что она сложнее).
Сложнее, потому что приходится писать, проверять и поддерживать в рабочем состоянии больше кода. Нередко в 2-3 раза больше.
N>Во-вторых, кому Вы возражаете? Я не говорил, что она с ним проще.
Я возражаю вашим словам строчкой выше — "TDD этого ... в общем случае не требует, а косвенно, наоборот, обещает ..., что code review при TDD нужен меньше — потому что всё покрыто тестами."
A>> Это та цена, которую мы платим за предсказуемость результат и уменьшение времени отладки. Те, кто считает, что с TDD можно будет ничего не делать и писать код тяп-ляп, а оно как-нибудь само, сильно заблуждаются. N>С какой ветряной мельницей Вы спорили на этот раз?
Да с вами же. С вашей позицией "в реальной жизни TDD не работает". Мои слова подкреплены реальным успешным опытом, а ваши? Ну если не считать экспериментальных попыток "попробовали что-то такое, ничего не получилось, ну и хрен с ним, некогда разбираться — работать надо".
Здравствуйте, abibok, Вы писали:
N>>Я говорил про TDD, а Вы начали про юнит-тесты в целом. Вы не замечаете подмены тезиса со своей стороны? A>Хорошо, у вас был опыт применения TDD на реальном проекте? С какими трудностями столкнулись? Почему считаете, что TDD не работает?
Потому что обнаружилось следующее:
1. Формальное прохождение заранее рассчитанных тестов недостаточно для проверки адекватности реализации. Особенно это проявляется в том, что является неизбежной спецификой реализации, но не оказалось заранее рассчитано на момент проектирования уровня (когда фиксируется состав тестов).
2. Проверка теста по принципу "вначале не работал, теперь работает" некорректна в принципе, и наблюдались случаи, когда проверка оказывалась некорректной по реализации, но это не могло быть распознано.
3. Метод "сначала свалимся" не работает как минимум в случае изменения самих тестов — например, в случае обновления тестирующей подложки.
A> Я стал говорить о юнит-тестах, потому что это один из ключевых компонентов TDD. В данном случае в моей фразе все слова "юнит тесты" можно заменить на "TDD", от этого смысл не изменится, просто постановка вопроса станет более общей. Если хотите еще шире, то замените "TDD" на "XP".
Я не хочу делать ни первую замену, ни вторую, потому что они обе некорректны. Юнит-тесты существуют отдельно от TDD, а XP — значительно более обширное понятие.
N>>Я, наоборот, говорил, что для эффективного применения TDD необходимым условием является высококачественное планирование, A>Да, но не в привычном waterfall стиле.
Спасибо, кэп.
N>>умный заказчик, который знает, чего хочет A>Это не обязательно. Большинство заказчиков не способны четко и исчерпывающе сформулировать ТЗ в начале проекта. TDD как раз помогает работать с такими реальными заказчиками.
Вот тут XP — возможно, помогает (по крайней мере, если заказчик начинает нести чушь, можно это опознать пораньше), а при чём тут TDD?
N>>изначально правильная архитектурная разработка (что может определиться только постфактум) A>Это тоже не обязательно. TDD позволяет изменять архитектуру в процессе работы, не боясь что проект станет нестабильным и все начнет сыпаться.
Только вот он на этом этапе удваивает работу — когда ты даже прототип не можешь нарисовать без тестов.
N>>В более реальных условиях он перестаёт работать, и от него остаются только лулзы для менеджера. A>Если менеджер не имеет опыта применения TDD, но с горящими глазами бросился внедрять новую игрушку, прочитав пару статей на тему, то да — игрушкой и останется. В противном случае, да еще и в условиях высокой дисциплины разработки в команде, TDD не то что хорошо работает, а даже я бы сказал является незаменимой техникой. Как нельзя программировать без классов, так нельзя делать проекты без TDD.
С высокой дисциплиной разработки в команде TDD ничего не меняет. Написаны тесты до кода или после, тесты всё равно адекватны и без прохождения тестов код не будет сдан как сделанный. А вот с плохой дисциплиной и исполнением на тяп-ляп он является средством замаскировать проблемы (как же, тесты есть — а их адекватность никого не волнует).
N>>А даже если планирование есть, чем оно поможет, если заказчик изменил требования? A>Если планирование есть, то проект может получиться, а может провалиться. А вот если планирования нет, то начиная с определенного уровня сложности проект обречен на провал. Планирование само себе не гарантирует успеха, но является его необходимым требованием. У нас говорят "Failing to plan is planning to fail" и я сам не раз убеждался, что скорость кодирования или индивидуальное мастерство программистов стоят далеко не на первом месте и важны куда менее, чем грамотное планирование и хороший communication.
A>>> либо когда из всего процесса TDD берут одни только юнит-тесты и пытаются прикрутить их к legacy проекту. N>>О да. Это не царь-батюшка плохой, это бояре его волю переврали. A>При чем здесь царь и бояре? TDD — достаточно сложная и имеющая массу нюансов при практическом применении техника. Если вы вдруг решили написать сотню тестов в готовом проекте, то это что угодно, кроме TDD.
N>>>>А если вмешивается заказчик, заставляя всё перепахать, то от его обоснований вообще ничего не остаётся. A>>>На практике вариант "все переделать с нуля" как правило не встречается, а если встречается, то с заказчиком заключается новый договор на разработку новой программы. Что происходит в реальности, это "что-то писали в течение года, потом показали заказчику и оказалось, что за год бизнес-задачи поменялись, на момент составления ТЗ заказчик сам не до конца понимал чего ему нужно, а программисты это еще и не так интерпретировали".
N>>Хм. Кто-то говорил только что о правильном планировании и взаимодействии с заказчиком, а теперь рассказывает про то, что показал что-то через год?
A>Читайте внимательно. "Показали через год" — это негативный пример, который показывает как делать не надо. TDD здесь и не пахнет, даже если разработчики пытались писать какие-то тесты.
N>>>>Правило "сначала тест, потом код" в TDD имеет два смысла. Первый — административный — выполнение такого рода процедуры проще обеспечить и соблюсти общий порядок, чем, если код уже написан, тянуть со временем и с деньгами, чтобы выдать релиз ("чего вы тянете, оно же всё написано и у тестера Маши даже показало результат! немедленно начинать продавать!") A>>>Какое отношение имеют юнит тесты с "показало результат"? Ладно бы функциональные или приемочные, но юнит тесты?
N>>Самое прямое. Юнит-тест — это функциональный тест для компоненты нижнего уровня (функции, класса). Показало результат — это показало соответствие кода ожиданиям этого теста.
A>Простите, но у вас каша в голове.
Судя по Вашему дальнейшему рассказу и тому, чему именно Вы тут возражаете, эта каша существует чисто в Вашем воображении. Что Вы туда намешали — я даже боюсь предположить.
A> Начиная с того, что тестеры не занимаются написанием и выполнением юнит-тестов и заканчивая смешивание понятий функционального и юнит тестов. То что в проекте успешно проходят юнит тесты абсолютно ничего не говорит о пригодности проекта к релизу или даже к способности проекта выполнять хотя бы какой-то полезный для заказчика функционал.
Потрясающе. Сначала Вы зачем-то вспомнили тестеров, хотя я про них ни слова не сказал. Далее приписали заведомо некорректный и непонятно откуда взявшийся вывод и успешно его опровергли. Так держать!
A> "Проходимость" юнит-тестов — это, пожалуй, наименее информативная из всех метрик. Можете повесить на стенку мраморную табличку, где будет выбита прямая линия и написано "Pass — 100%". Эта табличка будет актуальна для любого проекта на многие годы просто потому что такова природа юнит-тестов, они всегда проходят на 100%.
Вы тут заговариваетесь и опровергаете сам себя. Тут "всегда проходят", а перед этим "если проходят"...
Я уже боюсь предполагать, что Вы мне припишете в следующий раз.
N>>>>Второй — это хоть какая-то надёжность работы самого теста. A>>>Да, одно из преимуществ написания теста до кода — это возможность убедиться в том, что тест способен валиться. Иначе легко получить тесты, которые проходят вообще всегда, независимо от качества реализации тестируемой функции.
N>>То, что Вы говорите — расхожий миф, исходящий из авторов красивых книг и не имеющий никакого отношения к реальности. A>Расскажите как обстоят дела в вашей реальности.
А я это тут всё время и рассказываю.
N>>Да, написать тест, который зовёт функцию и проверяет результат — это гарантированный способ сломать тест, пока функции ещё нет. Но если тест, например, проверяет, что функция вообще что-то вернула, но игнорирует её значение, то он окажется удовлетворённым при любой реализации функции. A>Тест должен сначала не пройти, а потом, после реализации функции или исправлении бага — пройти. Принципиальное значение имеет факт такого перехода от fail к pass, а не просто "всегда fail" или "всегда pass".
Принципиальное значение для кода, который должен жить, а не один раз быть сданным и всё, является то, что всегда можно проверить, причём автоматизированно, что он fail, когда реализация нарушена. Однократная проверка вначале — это не проверка, тест мог начать работать чисто случайно.
N>>А бесконтрольное соответствие принципу "сначала тест, потом код" без оценки качества кода и теста — ничего не даёт A>С чего вы взяли что такой подход будет называться TDD? Кто сказал, что написание тестов позволит обходиться без оценки качества?
С того, что формальное определение TDD ничего не говорит про оценку качества, а при работающем административном обеспечении качества основные подходы TDD теряют значимость. Остаётся промежуточный случай — когда менеджер хочет обеспечить качество, но не знает, как. И вот в этом случае ему может помочь TDD (а может и не помочь, если исполнители обучились махлевать).
N>>кроме уже описанного мной ранее средства самоорганизации (тест является видимой и описанной целью, требующей удовлетворения). A>Маленькие дети, когда не хотят делать уроки, начинают раскладывать на столе тетрадки, точить карандаши и прочими способами имитировать бурную деятельность. Лишь бы не работать. Так и здесь, если вам необходимо нечто, о чем можно отчитаться начальству как о внедрении и средстве самоорганизации — ок, но не говорите потом что TDD не работает, потому что такое применение — это не TDD.
Нет, мне такое не нужно.
N>>>>Но, заметьте, TDD этого (ревью кода тестов) в общем случае не требует, а косвенно, наоборот, обещает (для стандартной психологии менеджера), что code review при TDD нужен меньше — потому что всё покрыто тестами. A>>>TDD ничего подобного не обещает. На самом деле разработка с TDD сложнее, чем без TDD. N>>Во-первых, не вижу обоснования этому тезису (что она сложнее). A>Сложнее, потому что приходится писать, проверять и поддерживать в рабочем состоянии больше кода. Нередко в 2-3 раза больше.
Моя практика ничего подобного не показывает. Интересно, какие у вас задачи и как вы именно решаете, что от отсутствия предварительного написания тестов код размножается в 2-3 раза? Не могу себе представить механизм для этого.
N>>Во-вторых, кому Вы возражаете? Я не говорил, что она с ним проще. A>Я возражаю вашим словам строчкой выше — "TDD этого ... в общем случае не требует, а косвенно, наоборот, обещает ..., что code review при TDD нужен меньше — потому что всё покрыто тестами."
Тогда непонятен общий характер возражения. Я как раз говорю, что TDD не улучшает разработку.
A>>> Это та цена, которую мы платим за предсказуемость результат и уменьшение времени отладки. Те, кто считает, что с TDD можно будет ничего не делать и писать код тяп-ляп, а оно как-нибудь само, сильно заблуждаются. N>>С какой ветряной мельницей Вы спорили на этот раз? A>Да с вами же. С вашей позицией "в реальной жизни TDD не работает". Мои слова подкреплены реальным успешным опытом, а ваши? Ну если не считать экспериментальных попыток "попробовали что-то такое, ничего не получилось, ну и хрен с ним, некогда разбираться — работать надо".
Ваши слова будут подкреплены реальным успешным опытом, когда будет сравнение двух очень сходных по сути разработок (а лучше вообще идентичных) со сходными исполнителями, но в одном случае с чётким следованием TDD, а в другом — без. И даже не так, а на массиве проб, среди которых и идеальные исполнители, и бардачные до предела. А на сейчас Ваша позиция ничем не отличается от "95% заболевших проказой ели свежие огурцы => огурцы вызывают проказу", потому что Вы не в состоянии отделить без массива проб влияние TDD и влияние таких факторов, как общее качество организации проекта и административной работы, уровень и методы работы исполнителей, и так далее. Пока что Вы говорите только о своих (или начальника) хороших организационных способностях.
А вот для опровержения общности вывода достаточно одного контрпримера, и я такие контрпримеры здесь и в соседних тредах приводил.
N>Потрясающе. Сначала Вы зачем-то вспомнили тестеров, хотя я про них ни слова не сказал. Далее приписали заведомо некорректный и непонятно откуда взявшийся вывод и успешно его опровергли. Так держать!
Вот ваши слова: "чего вы тянете, оно же всё написано и у тестера Маши даже показало результат! немедленно начинать продавать!"
A>>Сложнее, потому что приходится писать, проверять и поддерживать в рабочем состоянии больше кода. Нередко в 2-3 раза больше. N>Моя практика ничего подобного не показывает. Интересно, какие у вас задачи и как вы именно решаете, что от отсутствия предварительного написания тестов код размножается в 2-3 раза? Не могу себе представить механизм для этого.
Объем тестов может превышать объем product code в 2-3 раза. Если тесты не писать, то поддерживать этот дополнительный объем не нужно.
N>>>Во-вторых, кому Вы возражаете? Я не говорил, что она с ним проще. A>>Я возражаю вашим словам строчкой выше — "TDD этого ... в общем случае не требует, а косвенно, наоборот, обещает ..., что code review при TDD нужен меньше — потому что всё покрыто тестами." N>Тогда непонятен общий характер возражения. Я как раз говорю, что TDD не улучшает разработку.
Facepalm. Ну как еще объяснить, если вы не помните что сами же писали строчкой выше и в одном и том же абзаце опровергаете сами себя?
Здравствуйте, abibok, Вы писали:
A>Вот ваши слова: "чего вы тянете, оно же всё написано и у тестера Маши даже показало результат! немедленно начинать продавать!"
Ооо, так Вы начали читать, на что возражаете. Шарман, шарман. Да, каюсь: такого подвига я не ожидал и не подключил контекст предыдущих (до Вас) разговоров в этом треде. Но Вы начали свои возражения, отвергнув всё, что было написано до того, по принципу "Командир сказал: хорёк!", так что такое ограничение контекста было естественно. А теперь, оказывается, есть и суслики. В таком случае, сообщаю, что я принципиально отказываюсь обсуждать поднятые вопросы в предлагаемом Вами стиле "у меня всё работает, а у кого нет — пусть лечится". Я привёл в этом треде кучу технических возражений против основных подходов TDD, составляющих его принципиальную основу. Если Вы не согласны — пожалуйста, или опровергните хотя бы часть их, именно как технические возражения, или опишите, что именно и как Вы понимаете под TDD (и почему взяты именно такие определения и понимания) и как в таком случае оно образует цельный и непротиворечивый подход. Особенно меня интересует столкновение с реальным миром, который или вообще не agile, или agile, но не такое. Например, если мы берём и дорабатываем чужую библиотеку (стандартный случай работы с legacy кодом), выживет ли Ваш подход в этом случае.
A>>>Сложнее, потому что приходится писать, проверять и поддерживать в рабочем состоянии больше кода. Нередко в 2-3 раза больше. N>>Моя практика ничего подобного не показывает. Интересно, какие у вас задачи и как вы именно решаете, что от отсутствия предварительного написания тестов код размножается в 2-3 раза? Не могу себе представить механизм для этого.
A>Объем тестов может превышать объем product code в 2-3 раза. Если тесты не писать, то поддерживать этот дополнительный объем не нужно.
Ага, понял. Пишете Вы как-то странно, логика плохо ловится. Тогда встречный вопрос: почему Вы считаете, что эта ситуация — какая-то специфика TDD? Наличие кода тестов — неотъемлемое свойство именно автоматизированных тестов, и это неизбежность. Это цена, которую надо платить за автоматизацию. Почему такой акцент именно на TDD?
N>>>>Во-вторых, кому Вы возражаете? Я не говорил, что она с ним проще. A>>>Я возражаю вашим словам строчкой выше — "TDD этого ... в общем случае не требует, а косвенно, наоборот, обещает ..., что code review при TDD нужен меньше — потому что всё покрыто тестами." N>>Тогда непонятен общий характер возражения. Я как раз говорю, что TDD не улучшает разработку.
A>Facepalm. Ну как еще объяснить, если вы не помните что сами же писали строчкой выше и в одном и том же абзаце опровергаете сами себя?
Вы в состоянии отличить чьи-то (в данном случае TDD) обещания и реальное выполнение? Судя по этому комментарию, нет.
(Ну тогда продолжайте голосовать за Путина/Януковича/Обаму/etc., это точно Ваш кандидат.)
Точно так же как нелепость такого теста по отдельности в случае ручного запуска.
