Ещё один типичный аргумент против юнит-тестов (не TDD, а вообще юнит-тестов) такой. При каждом изменении кода ломается огромная куча тестов, и на их починку тратится огромная куча времени. Очевидно, неразумно.
Но это говорит только о том, что эти тесты написаны неправильно. При изменении метода А должны ломаться только тесты, проверяющие этот метод — а их должно быть немного. Ну там, 2-5-10. ну может, 20. Поменять эти тесты — не такая уж большая работа.
Типичная логическая ошибка.
Отсутствие доказательств не является доказательством отсутствия.
Допустим, у нас нет доказательств преимущества TLD или TDD. Что теперь? Не будем ни о чём говорить? Ну не хотите — не говорите, а есть люди, которые хотят поговорить. Обменяться мнениями, рассказать о своём опыте. Я думаю, что это гораздо полезнее для понимания, чем доказательства.
Да вы всё передёргиваете. Никто и не просит никому верить на слово. Я вообще не хочу, чтобы кто-нибудь верил. Надо не верить, а понимать. А для этого не доказательства нужны, а объяснения. Вот я и пытаюсь объяснить, как я это вижу, почему я считаю это правильным, засчёт чего, по моему мнению, это работает лучше.
Я привёл айкидо как пример того, что сначала кажется неестественным, а оказывается очень эффективным. Всем же кажется, что дать в табло эффективнее, чем делать какие-то непонятные выпендрёжные движения? Вот точно так же с TLD vs TDD.
P.S. Видимо, мне повезло больше. Учителя принципы объясняли, ученики понимали.
Но вообще-то я думаю, что и в айкидо, и в TDD одних объяснений недостаточно. Можно объяснять сто раз, но начнёшь понимать, как это работает, только тогда, когда сам попробуешь. И попробуешь не один раз, естественно.
Да, учебные тесты — это хорошо.
Вообще это концепция «спайка». Когда имеешь дело с неизведанной областью (в т.ч. новой библиотекой), надо с ней сначала поэкспериментировать. Пишешь main метод, пишешь там какой угодно говнокод без тестов, экспериментируешь. Когда ты наконец понимаешь, как работает эта библиотека и как её надо будет использовать, стираешь все свои эксперименты и пишешь код с нуля через TDD.
P.S. Если Сипуление коварно возвращает объекты ошибок, то не ваша ли задача скрыть это от вашего пользователя? Возьмите эти ошибки, превратите в нормальные исключения — пусть ваш API будет хорошим. Почему все остальные должны мучаться?
Так это опасный путь. Никогда не знаешь заранее, что может сломаться. На самом деле сломаться может всё!
И вы забываете, что польза от тестов не только и не столько в том, что они обнаруживают ошибки. Они помогают разрабатывать код с хорошим дизайном, служат как документация и т.д.
IvanPonomarev А я поддержу AstarothAst. Мне тоже кажется, что количество нажатых клавиш сравнивать непродуктивно. Я так и сказал: «Абсолютно без разницы!» :)
И да, предлагаемые темы действительно очень интересны — про сторонние библиотеки, требования к уровню программиста и вред от TDD. Ну так давайте продолжим дискуссию?
P.S. AstarothAst Насчёт сторонних библиотек — TDD тут тоже хорошо подходит. Ты пишешь тест на свой код, который использует библиотеку X. Запускаешь тест и видишь, как эта библиотека ведёт себя. Это ведь гораздо эффективнее, чем экспериментировать с этой библиотекой на живом коде, где после каждого изменения нужно рестартовать/редеплоить/логиниться/и пр.
cheremin Я думаю, что не только для вас способ мышления «test first» контринтуитивен, а вообще для всех. И для меня тоже! Для нас всех более естественно сразу писать код.
И в этом весь фокус: надо заставить себя думать «контрестественно», потому что при таком подходе получается меньше ошибок и лучше дизайн кода. Движения в айкидо, например, тоже поначалу кажутся контрестественными.
Второй вопрос: совершенно верно, это прямой сигнал. Часто так и получается. Это и имеют в виду, когда говорит, что TDD приводит к лучшему дизайну.
Первый вопрос: тут есть разные мнения. Одни считают, что тестировать надо только публичные методы. Другие считают, что ради теста не грех и убрать модификатор «private».
Я лично считаю, что это зависит от сложности метода. Если он простой (комбинаций особо нет) и его легко проверить через какой-то другой публичный метод, то можно через публичный метод.
Если же метод сложный, то для него стоит написать много разных тестов с различными комбинациями входных параметров, то лучше убрать «private» и протестировать этот метод отдельно.
Успешно разрабатывает, говорите?
Ну да, люди на лошадях тоже успешно добирались из одного города в другой.
А кто сказал, что он без TDD работает эффективнее, чем с TDD?
Меня именно это интересовало. Чтобы это понять, я задал кучу вопросов. И из ответов сделал вывод, что не эффективнее. Фанатизм тут не при чём.
Значит, тебе приходится удерживать в голове очень большой контекст. Ты боишься «отвлечься» ещё и на тесты, потому что тогда уж точно расплескаешь.
Но такой подходит не скалируется! Станет контекст чуть-чуть больше — и расплескаешь. Отвлечёшься не на тесты, а на что-то другое — расплескаешь. По-любому расплескаешь.
Поэтому я и говорю про концепцию «workspace». Это то, что ты пытаешься одновременно удерживать в голове, и надо стараться его минимизировать. Смотрел доклады Максима Дорофеева? «Джедайская техника пустого инбокса», «Мыслепатроны» — вот это всё. Удерживать что-то в голове — крайне расточительно. Наш мозг очень плохо умеет это делать и тратит на это много энергии — быстро устаёт. Зато мозг хорошо умеет думать — этим и надо его максимально нагружать. А задачу удержания контекста перекладывать на компьютер. То есть случае TDD — на тесты.
P.S. Писать тест на приватные методы — очень даже неплохая мысль. Ничего, что они постоянно меняются. Тесты как раз будут помогать их менять. Приватные методы — это тоже API, пусть невидимый снаружи. Это API для самого важного человека во вселенной — для тебя! :) Он тоже должен быть удобным.
cheremin Знаете, в чём отличие между заинтересованным человеком и троллем?
Заинтересованный человек всегда спросит, а как именно это работает. Засчёт чего. Каким образом решает проблему. А тролль требует доказательств.
В том время как доказательства как раз должны волновать меньше всего. Всегда можно сделать исследования, доказывающие любую точку зрения. Вы опыты на физике ставили в школе? Результаты подгоняли? Ну вот.
Если мне кто-нибудь предоставит «доказательства» того, что C++ круче Java, оно мне будет до лампочки. Я захочу узнать: а чем именно лучше? Засчёт чего? Как это работает? Решает ли это «лучше» именно мои реальные проблемы, или какие-то другие абстрактные?
Aingis Тогда тем более! Если нет разницы, чего вы вообще требуете тут? Тут собрались специалисты поделиться личным опытом и обсудить качественные различия, а вы требуете количественных доказательств. Не о том разговор.
Поддерживаю lany. Мутационное тестирование — красивая идея, но на практике мне не удалось его применить. Именно потому, что
1. Оно очень долгое
2. Оно даёт много ложных срабатываний. В них приходится бесконечно копаться вручную. Это прост нереально.
vintageIvanPonomarev Нет, вы что, такой способ как раз не даёт никаких гарантий.
Допустим, у нас есть уже написанный метод `hypotenuse` (и в нём есть баги).
По вашей методологии, мы пишем красный тест:
assertEqual(hypotenuse(3, 4) * 0 , 99);
Потом меняем константу в тесте:
assertEqual(hypotenuse(3, 4) * 0 , 0);
и вуаля — по-вашему, мы получаем гарантию, что метод правильный и тест его действительно проверяет!
А покажите мне сколько-либо достоверные исследования, доказывающие реальную эффективность «Не TDD»?
Таких исследований тем более нет!
Похоже, вы просто по умолчанию считаете одну позицию правой, в вторая должна вам доказывать свою правоту. :)
На самом деле никто ведь не пытается вам что-то доказать — ни исследованиями, ни мнением экспертов. По крайней мере, в этой статье. Что мы пытаемся — это привести аргументы обеих сторон, чтобы читатели могли сами разобраться. Пытаемся логически объяснить обе позиции. Для этого и нужен диалог. Эта статья — это диалог, вы заметили? :)
Ещё один типичный аргумент против юнит-тестов (не TDD, а вообще юнит-тестов) такой. При каждом изменении кода ломается огромная куча тестов, и на их починку тратится огромная куча времени. Очевидно, неразумно.
Но это говорит только о том, что эти тесты написаны неправильно. При изменении метода А должны ломаться только тесты, проверяющие этот метод — а их должно быть немного. Ну там, 2-5-10. ну может, 20. Поменять эти тесты — не такая уж большая работа.
Отсутствие доказательств не является доказательством отсутствия.
Допустим, у нас нет доказательств преимущества TLD или TDD. Что теперь? Не будем ни о чём говорить? Ну не хотите — не говорите, а есть люди, которые хотят поговорить. Обменяться мнениями, рассказать о своём опыте. Я думаю, что это гораздо полезнее для понимания, чем доказательства.
Я привёл айкидо как пример того, что сначала кажется неестественным, а оказывается очень эффективным. Всем же кажется, что дать в табло эффективнее, чем делать какие-то непонятные выпендрёжные движения? Вот точно так же с TLD vs TDD.
P.S. Видимо, мне повезло больше. Учителя принципы объясняли, ученики понимали.
Но вообще-то я думаю, что и в айкидо, и в TDD одних объяснений недостаточно. Можно объяснять сто раз, но начнёшь понимать, как это работает, только тогда, когда сам попробуешь. И попробуешь не один раз, естественно.
Вообще это концепция «спайка». Когда имеешь дело с неизведанной областью (в т.ч. новой библиотекой), надо с ней сначала поэкспериментировать. Пишешь main метод, пишешь там какой угодно говнокод без тестов, экспериментируешь. Когда ты наконец понимаешь, как работает эта библиотека и как её надо будет использовать, стираешь все свои эксперименты и пишешь код с нуля через TDD.
P.S. Если Сипуление коварно возвращает объекты ошибок, то не ваша ли задача скрыть это от вашего пользователя? Возьмите эти ошибки, превратите в нормальные исключения — пусть ваш API будет хорошим. Почему все остальные должны мучаться?
И вы забываете, что польза от тестов не только и не столько в том, что они обнаруживают ошибки. Они помогают разрабатывать код с хорошим дизайном, служат как документация и т.д.
Вкратце содержание таково:
И да, предлагаемые темы действительно очень интересны — про сторонние библиотеки, требования к уровню программиста и вред от TDD. Ну так давайте продолжим дискуссию?
P.S. AstarothAst Насчёт сторонних библиотек — TDD тут тоже хорошо подходит. Ты пишешь тест на свой код, который использует библиотеку X. Запускаешь тест и видишь, как эта библиотека ведёт себя. Это ведь гораздо эффективнее, чем экспериментировать с этой библиотекой на живом коде, где после каждого изменения нужно рестартовать/редеплоить/логиниться/и пр.
И в этом весь фокус: надо заставить себя думать «контрестественно», потому что при таком подходе получается меньше ошибок и лучше дизайн кода. Движения в айкидо, например, тоже поначалу кажутся контрестественными.
Первый вопрос: тут есть разные мнения. Одни считают, что тестировать надо только публичные методы. Другие считают, что ради теста не грех и убрать модификатор «private».
Я лично считаю, что это зависит от сложности метода. Если он простой (комбинаций особо нет) и его легко проверить через какой-то другой публичный метод, то можно через публичный метод.
Если же метод сложный, то для него стоит написать много разных тестов с различными комбинациями входных параметров, то лучше убрать «private» и протестировать этот метод отдельно.
Ну да, люди на лошадях тоже успешно добирались из одного города в другой.
А кто сказал, что он без TDD работает эффективнее, чем с TDD?
Меня именно это интересовало. Чтобы это понять, я задал кучу вопросов. И из ответов сделал вывод, что не эффективнее. Фанатизм тут не при чём.
Но такой подходит не скалируется! Станет контекст чуть-чуть больше — и расплескаешь. Отвлечёшься не на тесты, а на что-то другое — расплескаешь. По-любому расплескаешь.
Поэтому я и говорю про концепцию «workspace». Это то, что ты пытаешься одновременно удерживать в голове, и надо стараться его минимизировать. Смотрел доклады Максима Дорофеева? «Джедайская техника пустого инбокса», «Мыслепатроны» — вот это всё. Удерживать что-то в голове — крайне расточительно. Наш мозг очень плохо умеет это делать и тратит на это много энергии — быстро устаёт. Зато мозг хорошо умеет думать — этим и надо его максимально нагружать. А задачу удержания контекста перекладывать на компьютер. То есть случае TDD — на тесты.
P.S. Писать тест на приватные методы — очень даже неплохая мысль. Ничего, что они постоянно меняются. Тесты как раз будут помогать их менять. Приватные методы — это тоже API, пусть невидимый снаружи. Это API для самого важного человека во вселенной — для тебя! :) Он тоже должен быть удобным.
Заинтересованный человек всегда спросит, а как именно это работает. Засчёт чего. Каким образом решает проблему. А тролль требует доказательств.
В том время как доказательства как раз должны волновать меньше всего. Всегда можно сделать исследования, доказывающие любую точку зрения. Вы опыты на физике ставили в школе? Результаты подгоняли? Ну вот.
Если мне кто-нибудь предоставит «доказательства» того, что C++ круче Java, оно мне будет до лампочки. Я захочу узнать: а чем именно лучше? Засчёт чего? Как это работает? Решает ли это «лучше» именно мои реальные проблемы, или какие-то другие абстрактные?
1. Оно очень долгое
2. Оно даёт много ложных срабатываний. В них приходится бесконечно копаться вручную. Это прост нереально.
Допустим, у нас есть уже написанный метод `hypotenuse` (и в нём есть баги).
По вашей методологии, мы пишем красный тест:
Потом меняем константу в тесте:
и вуаля — по-вашему, мы получаем гарантию, что метод правильный и тест его действительно проверяет!
Так нет гарантии, что этот новый (изменённый) тест что-то тестирует.
Таких исследований тем более нет!
Похоже, вы просто по умолчанию считаете одну позицию правой, в вторая должна вам доказывать свою правоту. :)
На самом деле никто ведь не пытается вам что-то доказать — ни исследованиями, ни мнением экспертов. По крайней мере, в этой статье. Что мы пытаемся — это привести аргументы обеих сторон, чтобы читатели могли сами разобраться. Пытаемся логически объяснить обе позиции. Для этого и нужен диалог. Эта статья — это диалог, вы заметили? :)