[истории успеха] Разработка через тестирование

Почему «снова»? Речь шла о тестировании только в контексте TDD. Никто тестирование в отрыве не обсуждал. Я надеюсь...

> Никто тестирование в отрыве не обсуждал. Я надеюсь...

Не, ну понятно, что наш с dizza срач о терминах к TDD отношения не имеет. :3

2Lamerok

а какой софт используешь для верификации? или ты всё в ручную? используешь model checking? интересно стало.

А оно тут есть - обилие говнотестов висит грузом на интерфейсах, и когда их надо отрефакторить, возникает желалание этого не делать, чтобы не дрочиться с тестами. Отсюда мораль: тесты - кандалы на ногах рефакторинга.

Если это именно рефакторинг, то существуют автоматические средства, которые частично автоматизируют внесение изменений в код (в том числе тестов). Так что проблема решаема.

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

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

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

> или ты всё в ручную?

В ручную. Я работаю не в авионике, бюджета на докозательтво у меня нет.

При одной мысли об объёмах правки тестов на ВСЕ инваринаты входных данных, которые бы пришлось сделать, мне становиться не по себе.

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

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

слово «сомнительного» - лишнее, а так верно

Я ведь вовсе не говорю, что ТДД не работает. Работает, наверно... Весь вопрос в эффективности.

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

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

ок, пусть так

И самое главное - это не ответ на вопрос, чё делать с кодом тестов при изменении контрактов используемого в программе кода.

это всё от того, что Вы неправильно применяете TDD, модульные тесты не должны зависеть от деталей внутренней реализации, все тесты должны ходить через API и тестировать поведение тестируемых функций с точки зрения их пользователей, тогда при рефакторинге ничего не надо будет переделывать

Еще раз напомню, речь не о том, что «это не работает», речь об эффективности трудозатрат.

если «это работает», значит трудозатраты эффективны, не?

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

У меня сделать в живую не получилось. Не в смысле написания тестов, а в смысле трудозатрат на поддержку и синхронизацию тестов с самим продуктом, так что я пока что предпочитаю code review.

1. TDD - это достаточно сложная в применении практика, даже у опытных программистов уходит до 4-6 месяцев, чтобы освоить её в нормальном объёме
2. code review и TDD понятия дополняющие друг друга, но никак не взаимоисключающие

> или ты всё в ручную?

В ручную. Я работаю не в авионике, бюджета на докозательтво у меня нет.

сам того не понимаешь ты тратишь гораздо больше времени на это «не доказательство», с гораздо худшим результатом :)

что такое модульное тесты? это просто записанные твои ручные тесты, которые ты все в автоматическом режиме регулярно прогоняешь, не избирательно, а в полном объёме :)

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

Где я говорил, что должны?

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

Это бессмыслица. Вот живой пример:

http://wiki.agiledev.ru/doku.php?id=tdd:tests_automation_with_simple_test

Рефакторинг с работающими тестами

Вот отрефакторенная версия:

if (preg_match('/^(.*?)\s+(.*)$/', $line, $matches))

Грубая ошибка на лицо. Ладно, чувак мужественно признаёт это:

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

Докидывает еще несколько мусорных тестов:

Мы повторяем этот цикл, пока не сможем придумать как можно больше адекватных тестов. Пройдя еще пять циклов, вот что мы получаем:

И в результате он всё равно остаётся с грубейшей ошибкой:

И вот как выглядит код:

if (preg_match('/^(\w+)\s+(.*)/', $line, $matches))

Это как раз из-за того, что чувак «тестировал апи» какими-то мифическими «адекватными тестами», вместо того, чтобы тупо протестировать реализацию на инварианты.

> сам того не понимаешь ты тратишь гораздо больше времени на это «не доказательство», с гораздо худшим результатом :)

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

> если «это работает», значит трудозатраты эффективны, не?

Не. Можно носить воду в сите, а можно в ведре. Бочонок наполнится в обеих случаях, но с разными трудозатратами.

> 2. code review и TDD понятия дополняющие друг друга, но никак не взаимоисключающие

Вопрос не в том, кто кого взаимоисключает. Вопрос в том, на что хватает времени == денег.

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

Где я говорил, что должны?

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

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

Это бессмыслица.

нет, это how the things should be

Вот живой пример:

http://wiki.agiledev.ru/doku.php?id=tdd:tests_automation_with_simple_test

живой пример чего? всё тестирование осуществляется через публичный интерфейс класса, детали реализации не трогаются, чего Вам ещё надо?

Это как раз из-за того, что чувак «тестировал апи» какими-то мифическими «адекватными тестами», вместо того, чтобы тупо протестировать реализацию на инварианты.

это всего лишь простой пример, он должен показывать подход, не стоит ожидать от него слишком многого

> сам того не понимаешь ты тратишь гораздо больше времени на это «не доказательство», с гораздо худшим результатом :)

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

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

> если «это работает», значит трудозатраты эффективны, не?

Не. Можно носить воду в сите, а можно в ведре. Бочонок наполнится в обеих случаях, но с разными трудозатратами.

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

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

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

>> Вот живой пример:

http://wiki.agiledev.ru/doku.php?Zd=tdd:tests_automation_with_simple_test

живой пример чего?

Методологической ошибки «тестируй код на предмет того, как он должен работать».

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

Корректного кода, очевидно же.

> это всего лишь простой пример, он должен показывать подход, не стоит ожидать от него слишком многого

Он даёт вполне себе - хороший пример ошибочности подхода.

> и как ты теперь будешь из своего метода устранять пресловутый «человеческий фактор»?

1. Зачем его устранять?
2. Тестирование его не устраняет совершенно. Скорее, TDD - результат человеческого фактора. Не уверенности программиста в том, что же именно он сделал. ;)

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

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

Не уверенности программиста в том, что же именно он сделал. ;)

У меня стойкое ощущение, что вы и не писали толком тестов. Попробуйте. Далее с вами дискутировать скучно и бессмысленно, примерно так же как и спорить о существовании бога.

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

А где я это говорил?

где-где, вот где:

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

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

должен сказать, что ты не очень убедительно бакланишь, харе ваньку валять

Методологической ошибки «тестируй код на предмет того, как он должен работать».

в чём ошибка?

Корректного кода, очевидно же.

за тебя его никто писать не будет, иди пиши

Он даёт вполне себе - хороший пример ошибочности подхода.

ну просто сам себе лучший собеседник - взял, поговорил сам с собой, сам себя убедил, и доволен остался, молодец!

> и как ты теперь будешь из своего метода устранять пресловутый «человеческий фактор»?

1. Зачем его устранять?

подумай, уверен ты поймёшь, это не сложно

Тестирование его не устраняет совершенно.

ещё как устраняет, и это доказано практикой людей его осилившего

Скорее, TDD - результат человеческого фактора.

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

Не уверенности программиста в том, что же именно он сделал. ;)

ну да в google, в ibm, в других крупных компаниях, работают сплошные неосиляторы, и только ламерок с лора рулит планетой

//не смеши тапки

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

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

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

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

А где я это говорил?

где-где, вот где:

Не дают, т.к. рефакторинг - это изменение API и, следовательно, изменение целой пачки тестов, его тестирующих.

харе ваньку валять

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

>> Методологической ошибки «тестируй код на предмет того, как он должен работать».

в чём ошибка?

В том, что «тестируя» код «как он должен использоваться» ты выполняешь друную работу. Этот код по-любому будет вызван во время прогона программы на тестировании. Если код будет работать не правильно - это будет видно. Тестировать надо в первую очередь на граничные условия.

Корректного кода, очевидно же.

за тебя его никто писать не будет, иди пиши

Склероз пробил или просто похамить захотелось?

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

Твои слова? Значит ты оправыдваешь ошибку реализации при наличии тестов? ;)

>> Он даёт вполне себе - хороший пример ошибочности подхода.

ну просто сам себе лучший собеседник - взял, поговорил сам с собой, сам себя убедил, и доволен остался, молодец!

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

Это же ты привёл в пример этот сайт как образчик методологии? Что ж ты теперь отмахиваешься от того факта, что чувак следующей этой методологии облажался?

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

дааааа... ну поехали по второму кругу:

Рефакторинг (англ. refactoring) — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы.

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

какого тестирования????

Если код будет работать не правильно - это будет видно. Тестировать надо в первую очередь на граничные условия.

и как это расходится с тем что я сказал? я Вам, между прочим, второй день уже на это намекаю

> всё тестирование осуществляется через публичный интерфейс класса, детали реализации не трогаются, чего Вам ещё надо?

Твои слова? Значит ты оправыдваешь ошибку реализации при наличии тестов? ;)

ты всегда разговариваешь сам с собой?

> ну просто сам себе лучший собеседник - взял, поговорил сам с собой, сам себя убедил, и доволен остался, молодец!

Конечно, лучше повалять дурачка на цирковой арене, чем отвечать по существу

рад, что Вы признаёте свои недостатки

Что ж ты теперь отмахиваешься от того факта, что чувак следующей этой методологии облажался?

ты сначала покажи где именно он облажался

>>> и как ты теперь будешь из своего метода устранять пресловутый «человеческий фактор»?

1. Зачем его устранять?

подумай, уверен ты поймёшь, это не сложно

Жаль тебя огорчать, но мне не платят за устранение себя из программирования. ;) А над вопросом как устранить меня думает масса гораздо более смышлёного чем я народу. Только что-то у них не получается.. ;)

Тестирование его не устраняет совершенно.

ещё как устраняет, и это доказано практикой людей его осилившего

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

Скорее, TDD - результат человеческого фактора.

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

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

ну да в google, в ibm, в других крупных компаниях, работают сплошные неосиляторы,

Не-не-не, Дэвид. Мифические гуглы с айбиэмами и прочие люди-икс не канают. Канает конкретный пример. Покажи код.©®™

> если Вы не осилили методологию - это не значит что она, внезапно, стала плохой, это значит, что Вы - неосилятор

Именно так. Я пытался ездить на этих лыжах, и получилость полохо. На роликах и велике получается быстрей. Хочу увидеть как лыжник обгоняет меня на нашем асфальте. ;)

> ну поехали по второму кругу:

Куда? Ты либо задай вопрос по-нормальному, либо заканчивай тупо флудить.

> какого тестирования????

Код, после написания, обычно исполняются. Чаще всего самим автором. Всегда ваш, кэп.

и как это расходится с тем что я сказал?

Вот с этим:

за тебя его никто писать не будет, иди пиши

?

>> Что ж ты теперь отмахиваешься от того факта, что чувак следующей этой методологии облажался?

ты сначала покажи где именно он облажался

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

>>> и как ты теперь будешь из своего метода устранять пресловутый «человеческий фактор»?

1. Зачем его устранять?

подумай, уверен ты поймёшь, это не сложно

Жаль тебя огорчать, но мне не платят за устранение себя из программирования.

чёрт, тупой как валенок

А над вопросом как устранить меня думает масса гораздо более смышлёного чем я народу. Только что-то у них не получается.. ;)

у Вас там комбинат лузеров, я это уже понял

> ну да в google, в ibm, в других крупных компаниях, работают сплошные неосиляторы,

Не-не-не, Дэвид. Мифические гуглы с айбиэмами и прочие люди-икс не канают. Канает конкретный пример. Покажи код.©®™

смотри

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

> ну поехали по второму кругу:

Куда? Ты либо задай вопрос по-нормальному, либо заканчивай тупо флудить.

не нужен вопрос, мне с тобой и так всё понятно, проблема в другом - ты порешь чушь и путаешься даже в 1-м определении, но делаешь это столь самозабвенно, что кто-то может может на твои рассуждения повестись, это было бы не очень хорошо

> какого тестирования????

Код, после написания, обычно исполняются. Чаще всего самим автором. Всегда ваш, кэп.

ты не кэп, ты мастер хелловордов

Если тесты писал и раньше, но после написания кода — то вообще не вижу проблемы, просто пиши тесты первыми. Подводные камни — перестаешь натыкаться на подводные камни не_tdd, и это немного настораживает.