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

Вот к пример участвовал в UaWebChallenge github.com/.../BattleBalancer и банально не было времени на тесты, но в голове они у меня были и направление движения мыслей, позволило быстро справиться с задачей. Другое дело, что я тратил время на постоянный перезапуск кода и проверку руками, что все работает.

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

Могут с уверенностью в 99%, что те, кто поддержали ваш комментарий (кроме 20% из них, в данном случае это один человек), не практикуют TDD.

Я делал это осознанно, провокационно и в итоге легко отсек в дискуссии необходимую мне подгруппу.

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

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

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

Согласен про ООП шелуху, даже можно просто алгоритм запилить сразу и писать тест только для него. В духе: загружаю такую-то картинку и получаю такой звук. А можно несколько иначе.

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

Я бы написал тест на извлечение дорожки из изображения пластинки, для реализации заюзал бы OpenCV или что там у вас для этих целей используется. Затем написал тест на разбиение дорожки, на блоки, типа передаю в метод дорожку Block[] split(PlateTrack track), а получаю блоки. Тоже не сложно написать. А далее, я бы писал тест на превращения такого блока в цифру звуку для метода SoundDigit mapToSound(Block block). Таких тестов было бы уже столько, сколько есть вариантов распознавания блока в цифру.

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

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

Я не путаю, я хотел сказать, что в языках на уровне библиотек предусмотрено. Вон в python есть uniitest либа. Только об этом.

Тесты переписываем только когда меняются требования.

Всем огромное спасибо за комментарии! Блин, жаль, что в ближайшее время не будет доступа к Интернету.

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

Дело в том, что я уже как год практикую TDD и как это бывает везде, сначала я слепо следовал подходу, а теперь уже с умом. Этот подход позволил мне писать быстрее, решать задачи качественнее, научил меня думать, я начал применять SOLID неосознанно. И вот я пришел сюда в конце года, что провести ретроспективный анализ. Хотел спросить, кто как пишет тесты и почему? Хотел как-то подитожить опыт собранный за год. Я обращался к тем, кто практикует TDD.

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

Всем огромное спасибо за дискуссию, за одно я получил некий срез специалистов на DOU для себя. Желаю всем огромных успехов в Новом Году и ребята, самое главное, желаю вам стать в следующем году намного лучше! Мы должны развиваться и становится лучше с каждым годом!

Всех с Новым Годом, не воспринимайте все так серьезно!

Да, Тим, есть места где я бы этот подход не применял или бы задумался. Я больше пишу о тех 80% случаев, где он применим.

Например, я не пишу тесты для CRUD, мне банально лень + знаю, что все что ниже — протестировано.

Это хороший код, я не считаю его говнокодом. Вы приводили этот пример и я писал вам ответ dou.ua/...-comment#612395

Все хорошо, если это в одном месте. Плохо, если начнете таскать такой код и дублировать. Тут дело даже не в тестах.

По поводу стандартов, вы сами сказали, что мера должна быть во всем. Значит и стандарт джавы может быть говно, в этом тоже должна быть мера. Вы же отлично понимаете, что через пару лет выйдет новый стандарт, который отменит этот. Это я не к примеру говорю, а к тому, что действительно мера должна быть во всем. В этом я с вами полностью согласен.

Все очень просто. По понятным причинам я не буду сейчас тратить свое время на решение этой задачи. Но какие-то считанные минуты у меня в этом году еще есть =)

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

1. Первый тест. Тестирую еще не существующий класс PlateSoundExtractor. У него будет метод Sound extractSound(imageFileName), который на вход получает путь к файлу, а на выходе выдает звук. Как я это буду тестировать? Все просто:

PlateSoundExtractor будет зависеть от ImageLoader и SoundExtractor. Я мокаю еще не существующий ImageLoader.load(imageFileName), что он будет возвращать изображение, а SoundExtractor.extractFromImage(Image) будет возвращать звук для картинки. Понятно, что там не статика, а конкретные инстансы.

Запускаю тесты, в PHP мои инструменты (phpspec) нагенерирует мне эти еще не существующие классы и методы.

На данном этапе у нас готова самая высокая абстракция PlateSoundExtractor.

2. Нужно описывать теперь ImageLoader. Здесь все понятно и очень просто. Нас интересует SoundExtractor.

Пишу для него тест с двумя зависимостями, первая ImagePixelsToSoundDigitsConverter с методом pixelsToSoundDigits() и вторая SoundFactory.fromDigits(). Мокаю их аналогично первому шагу. То есть я убеждаюсь, в корректном поведении методов.

На данном этапе у нас уже есть готовый SoundExtractor. Пора бы перейти к конкретным реализациям.

3. Осталось реализовать ImagePixelToSoundDigitsConverter и SoundFactory. Понятно, что тест для SoundFactory.create() будет очень прост. Получили на вход цифры и сгенерили на выходе звук. Нас интересует самое главное ImagePixelToSoundDigitsConverter.pixelsToSoundDigits().

Это самый главный метод и от него зависит успешное распознавание. Здесь я могу поступить двумя путями или уже писать на свой алгоритм или заюзать либу для нейронной сети. Могу это вынести при помощи стратегии и попробовать и так, и так.

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

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

Там есть человечек, который заменяет тесты =)

Но не смотря даже на это, если в репе ядра нет тестов — это не значит, что их нет вообще, они просто существуют отдельно.

Из того, что знаю linux-test-project.github.io. Думаю если погуглить, то еще найдется много тестов.

Если вы так и пишите код сразу и без багов. То тогда TDD вам не подходит и нет смысла с вами как-то спорить, ибо вам оно не нужно.

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

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

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

И еще раз, я не буду переписывать все тесты. Я буду переписывать тест, который соответствует изменению логики. А так как есть Single Responsibility Principle, то я буду переписывать только один тест и только одно место в коде.