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

давай уже

так чо сказать то хотел?

Если удается выделить код в отдельный модуль - пишу для него файл с тестами. Этот файл подключается через тег script и говорит в консоль браузера OK или FAIL. Это значительно уменьшает психическое напряжение когда требуется изменять модуль в будущем. С тестами код меняется куда смелее и непринужденнее.

А непосредственно для логики програмы не пишу. Там нужны какие-то другие тесты, поведенческие. ХЗ как их писать

Не всегда удается построить эффективные тесты для реальных систем.

Ну и тупизм. Это типа: не всегда удается строить эффективные системы для реального мира. Вывод - давайте перестанем программировать!

Самый плюс в том, что хорошо, когда тесты есть.

ППКС. А в чем минусы наличия тестов? Их нужно поддерживать?

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

Минус в том, что на них иногда уходит неоправданно много трудо-затрат

а если тесты выполняются во время написания кода?

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

и не все ошибки находятся вкратце.

пример

Что-то было у Спольски на эту тему. По-моему тут (читать примерно отсюда «Last week Kent Beck made a claim»). В голову с ходу пришли ошибки анализа и отсутствие конкретных требований к некоторым мелочам. Эти ошибки ты никак не выявишь, пока не сдашь продукт в эксплуатацию. В данном случае ошибка - это не плохо, а скорее корректировка требований. Плохо, конечно, если продукт весь состоит из таких ошибок, но TDD тут бессильно.

быстро вспоминаешь что к чему.

пример!

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

Ну и тупизм. Это типа: не всегда удается строить эффективные системы для реального мира. Вывод - давайте перестанем программировать!

продолжать автоматизировать хаос не смотря ни на что

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

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

Все так.

Заплатишь мне денег, какую-то часть покрою. Нытики, блин

Так пруфани, что ты хоть что-то можешь. Какой мне смысл тебя нанимать иначе.

Как задрал этот хайп вокруг ТДД. Аджайл-шмаджайл ТДД-шмдд. А так по-опыту, что с тестами, что без тестов в любом проекте есть косяки. При этом в проектах без ТДД, но хорошей проектной документацией (erd,workflow etc) ошибок на порядок меньше.

проверка кода или его куска в REPL или тестовой компиляцией без оформления тесткейса считается TDD?

Мне как-то предлагали работу по ТДД. Я посмотрел, как они там это делают... и понял, что таким макаром не напишу ничего и никогда. Извинился, соврал, что у меня важные дела, и свинтил оттуда.

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

Нет.

Да.

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

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

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

А мож это ты пруфанешь, что мне стоить на тебя время тратить?

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

Заплатишь мне денег, какую-то часть покрою.

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

Так! Вы оба! Быстро по углам и лицом к стенке! Устроили тут балаган, понимаешь! Взрослые мужики ... детский сад, блин. dizza не прикидывайся шлангом - тебя тоже касается!

Ассерты говорят, как код должен работать.

Ассерты говорят, что при написании программы разработчик полагался на волю Аллаха.

Вообще-то тест и должен быть дубликатом, на этом и строится тестирование.

Вообще-то нет. Копипаста — плохая вещь, в любом случае.

Да.

Что да? TDD это разработка, при которой ты пишешь тесты, которые у тебя остаются. Если ты пишешь с REPL-ом, а не с тестами, то это стандартная разработка, это не TDD.

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

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

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

Во-первых язык проекта просто так не поменяешь. Так что да, если ты пишешь на JS, тесты тем или иным образом должны проверять то, что на Java ты проверял бы компилятором. Но это всё равно надо проверять и тесты это делают. Не все могут писать на хаскеле, мало кто может это делать. Остальные вынуждены писать на менее типизированных языках и проверять то, что хаскель может проверять при компиляции, тестами.

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

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

Какая разница, где?

Или можешь экспериментировать в стиле TDD, почему у тебя не хватит времени? TDD априори требует больше времени. Закладывай это при планировании.

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

Так что да, если ты пишешь на JS, тесты тем или иным образом должны проверять то, что на Java ты проверял бы компилятором.

Слава яйцам, я на JS не пишу. Но иногда захожу на эту территорию. И вижу, какая там боль.

Сам бы я выбрал что-нибудь типа Elm, например.

Не все могут писать на хаскеле, мало кто может это делать.

Я пишу на Scala.

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

В ситуации, где ошибку вообще допустить нельзя — однохренственно.

Если у меня прямо в коде написано «sum [] = 0», то на кой хрен мне ещё писать «assert (sum [] = 0)»? У меня что, это когда-нибудь поменяется?

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

Тесты, разумеется, нужны. Но тесты нужны на то, что имеет смысл тестировать. И после написания первой версии кода — когда мы уже точно знаем, как этот код должен работать.

Не копипаста, а дублирование. И в тестировании без этого никак.

Не копипаста, а дублирование.

Томато-томэйто.

И в тестировании без этого никак.

Вполне как. Что-что, а тесты мы на работе пишем, и копипасты там нет.

Вообще-то тест и должен быть дубликатом, на этом и строится тестирование.

Тестирование строится на необходимости тестирования. В большинстве TDD-драйвен проектов тестируют какую-то чушь типа 2+2=4, потому что можно протестить однозначно, но что касается сложного функционала - тестируют тяп-ляп, потому, что написание полноценного теста займет несравнимо больше времени, чем имплементация. Так что любое *DD - это всего-лишь очередная крайность фанбоев.

В большинстве TDD-драйвен проектов тестируют какую-то чушь типа 2+2=4, потому что можно протестить однозначно

Вот-вот. А если постоянно писать тесты на 2+2=4, то на продуктивную работу уже никаких ресурсов не остаётся.

Так что любое *DD - это всего-лишь очередная крайность фанбоев.

Нет, TDD — неплохая вещь, если первое T понимать как Types.

Какая разница, где?

Экспериментировать лучше вне проекта. Чтобы случайно что-нибудь не испортить и не забыть потом отменить. VCS конечно помогает, но всё равно лучше на игрушечном проекте обкатать библиотеку или алгоритм.

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

Для этого тесты не подходят.

Я пишу на Scala.

А 99% остальных людей пишут на Java, PHP, C#. И им нужна стратегия, при которой будет получаться продукт, удовлетворяющий всем необходимым требованиям. Кроме того Scala это не что-то волшебное. Она может проверять больше, чем Java, естественно это тестировать не надо. Компилятор обычно работает без багов. Но необходимость тестов это не отменяет.

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

В ситуации, где ошибку вообще допустить нельзя — однохренственно.

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

Если у меня прямо в коде написано «sum [] = 0», то на кой хрен мне ещё писать «assert (sum [] = 0)»? У меня что, это когда-нибудь поменяется?

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

Тесты, разумеется, нужны. Но тесты нужны на то, что имеет смысл тестировать. И после написания первой версии кода — когда мы уже точно знаем, как этот код должен работать.

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

А если постоянно писать тесты на 2+2=4, то на продуктивную работу уже никаких ресурсов не остаётся.

Зачем писать такие тесты? TDD этого не требует.

Тестирование строится на необходимости тестирования.

То которое QA - да. То которое внутренне девелоперское тестирование - нет. Вообще TDD - это Test Driven _Development_, к QA это отношения не имеет.

. В большинстве TDD-драйвен проектов тестируют

Ну так это они косячат, при чем здесь методология?

Так что любое *DD - это всего-лишь очередная крайность фанбоев.

Есть другая крайность - нигилизм.

ППКС. Я уже задолбался писать тесты для ошибок.

цена добавления тест-кейса больше цены добавления 2-3 строчек

Я уже задолбался писать тесты для ошибок.

Щито?

it ('should return (no) error if document not found')

То которое QA - да

Это тут причем?

Вообще TDD - это Test Driven _Development_, к QA это отношения не имеет.

Не надо уводить разговор в сторону. Про QA вообще никто не упоминал, куда тебя понесло?

Это ты разговор уводишь в тестирование. А я про разработку, а не тестирование.

Я уже задолбался писать тесты для ошибок.

Щито?

it ('should return (no) error if document not found')

И? Должен - значит, должен. А если у тебя выбор между тем, чтобы написать дурацкий тест и полезный тест... в чем вообще вопрос?

Это ты разговор уводишь в тестирование.

Угадай, что в аббревиатуре TDD означает буква Т и как это переводиться на русский.

проверка кода или его куска в REPL или тестовой компиляцией без оформления тесткейса считается TDD?

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

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

я решил, что я НЕ ДОЛЖЕН писать эти тест кейсы.

Время написания тест кейса >>>>= время написания обработчика ошибок в колбеке.

Там негде ошибиться

я решил, что я НЕ ДОЛЖЕН писать эти тест кейсы.

Какие «эти»? ладно, забей. Тебе, похоже, русский не родной.

Там негде ошибиться

Famous last words.

А теперь угадай где в английском языке существительное, а где прилагательное и как расшифровывается последняя буква D.

Какие «эти»? ладно, забей.

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

Тебе, похоже, русский не родной.

яволь, геноссе!

Какие «эти»? ладно, забей.

тест кейсы, которые проверяют, правильно ли тестируемая фунцкия возвратила исключение

Я разрешаю тебе не писать бессмысленных тестов. Если сеньор будет возбухать - шли его сюда, я ему всё объясню.

а я у сеньора не спрашиваю. зачем ему знать мои проблемы?

и да, еще: а какие тесты нужно считать бессмысленными? Ну типа эвристики, ориентиры и т. п.

а то в тырнете только общая информация

Тогда еще проще - не пиши бессмысленные тесты. Просто не пиши.

дай определение «бессмысленности теста»

тест на 2+2=4 не предлагать. Он надуман. И ни о чем не говорит.

и да, еще: а какие тесты нужно считать бессмысленными?

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

а то в тырнете только общая информация

А она и может быть только общей.

дай определение «бессмысленности теста»

(пожимая плечами) Тест, не ускоряющий разработку.

дай определение «бессмысленности теста»

(пожимая плечами) Тест, не ускоряющий разработку.

Ура, мы наконец то узнали, зачем нужны тесты.

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

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

ОК?

мы наконец то узнали, зачем нужны тесты.

«Наконец-то»? Херасе.

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

Неверно.

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

«Я не могу ответить на твой вопрос в терминах Зодиака, потому что Зодиак не имеет к этому никакого отношения» (ц)